RAP - Änderungsbelege implementieren (Nativ)
Hast du das passende Release, dann kannst du Änderungsbelege auch mittlerweile nativ in RAP implementieren, ohne viel mnauelle Implementierung. Schauen wir uns dazu die verschiedenen Schritte an.
Inhaltsverzeichnis
In diesem Artikel schauen wir uns die native Implementierung der Änderungsbelege in RAP an und wie du im passenden Release die Funktion aktivierst.
Einleitung
Bereits in einem anderen Artikel hatten wir eine manuelle Implementierung der Änderungsbelege vorgenommen. Deshalb wollen wir in diesem Artikel noch einmal Anpassungen an unserer Sales App vornehmen und die Änderungsbelege automatisch erzeugen lassen. Dazu werden wir die aktuell eingebauten RAP-Fähigkeiten nutzen.
Vorbereitung
Damit wir die Belege nicht mehr manuell schreiben, kommentieren wir die Logik in der erweiterten Speichermethode aus. Dazu deaktivieren wir einfach die Aufrufe der verschiedenen Methoden innerhalb der Methode SAVE_MODIFIED. Diese Methode hatten wir für die manuellen Änderungsbelege implementiert und im letzten Artikel modifiziert, um den Code auszulagern. Daher ist das Auskommentieren relativ einfach, da nur noch die drei verschiedenen Methodenaufrufe deaktiviert werden müssen.
METHOD save_modified.
TRY.
DATA(helper) = NEW zcl_bs_demo_rap_auxiliary( ).
* helper->change_document_for_create( create ).
* helper->change_document_for_update( update ).
* helper->change_document_for_delete( delete ).
CATCH cx_chdo_write_error INTO DATA(error).
RAISE SHORTDUMP error.
ENDTRY.
ENDMETHOD.
Implementierung
Die neue Implementierung der Änderungsbelegreibung Werden nun in der Verhaltensdefinition definiert Punkt dazu. Gibt es neue Schlüsselwörter, die wir verwenden können. In der Dokumentation im unteren Bereich des Artikels findest du weitere Informationen zu den Schlüsselwörtern und Beispiele aus dem Standard.
Aktivierung
Bereits in den ersten Teilen der Serie hatten wir die Änderungsdokumentation an den Datenelementen aktiviert. Wenn du ein Datenmodell aufbaust, zum Beispiel auf Basis von Table Entities, kannst du auch mit Simple Types arbeiten. Für diese gibt es eine eigene Annotation, um die Änderungsdokumentation zu aktivieren, da es hier kein entsprechendes Flag in einem grafischen Editor gibt. Über die folgende Annotation aktivierst du die Belegschreibung:
@AbapCatalog.typeSpec.changeDocumentRelevant: true
Unter dem Punkt "typeSpec" kannst du auch weitere Einstellungen vornehmen, wie zum Beispiel den Conversion-Exit oder die Ausgabelänge.
Verhaltensdefinition (Aktivierung)
Um nun die Änderungsdokumente zu aktivieren, müssen wir in die Verhaltensdefinition gehen. Dort ergänzen wir an der Hauptentität den Zusatz CHANGEDOCUMENTS MASTER. Dazu gibt es einige Attribute, die wir pflegen können, mehr dazu findest du in der Dokumentation. In diesem Fall setzen wir das Mapping auf UTC, damit die erzeugten Einträge in UTC-Zeit gespeichert werden. Dahinter geben wir das eigentliche Change-Objekt an, welches wir im ersten Artikel angelegt haben. Die Definition der Entität SASale sieht nun wie folgt aus.
define behavior for ZBS_R_SASALE alias SASale
persistent table zbs_sasale
...
authorization master ( global )
with additional save
changedocuments master utc ( ZBS_CO_SALES )
Das Gleiche müssen wir jetzt noch bei allen abhängigen Entitäten durchführen. Hier verwenden wir aber nicht, dass Master, sondern dass CHANGEDOCUMENTS DEPENDENT, um auf unsere Root-Entität zu verweisen, wo wir den eigentlichen Änderungsbeleg definiert haben.
define behavior for ZBS_R_SASELLER alias SASeller
persistent table zbs_saseller
...
authorization dependent by _SASale
with additional save
changedocuments dependent by _SASale
Verhaltensdefinition (Logging)
Nachdem wir nun für die einzelnen Entitäten die Änderungsdokumentation aktiviert haben, müssen wir in der Verhaltensdefinition noch die entsprechenden Eigenschaften für die verschiedenen CRUD-Operationen festlegen. Dafür gibt es wieder das Keyword CHANGEDOCUMENTS. Dort werden die Eigenschaften für Create, Update und Delete gepflegt. Hinter der jeweiligen Operation gibt man den Modus an, wie protokolliert werden soll. In diesem Fall stehen drei verschiedene Varianten zur Verfügung: None, Data und Key.
changedocuments ( create : data, update : data, delete : key );
Hier findest du noch eine Erklärung der verschiedenen Werte:
- None - None bedeutet, dass kein Logging für diese Operation erfolgt.
- Key - Bei Key wird nur der entsprechende Schlüssel protokolliert.
- Data - Und bei Data werden alle Daten und Felder, die für die Änderung vorgesehen sind, geloggt.
Anzeige
Grundsätzlich können wir uns weiterhin über die wiederverwendbare ABAP-API die Daten anzeigen lassen. SAP liefert aber auch einen Core Data Service I_ChangeDocument_2 aus, den wir verwenden können, um uns die Änderungsbelege anzusehen oder sie direkt in unsere Anwendung einzubinden. In diesem Fall verwenden wir den Core Data Service, um unser Datenmodell anzureichern und die Änderungen später im UI sichtbar zu machen. In der offiziellen SAP-Dokumentation für die RAP-Implementierung findest du weitere Details zu den Views und wie du die Implementierung am besten vornimmst.
Hinweis: Die aktuelle Implementierung im ABAP Environment funktioniert leider noch nicht. Es kommt zu einer Fehlermeldung, wenn wir den CDS View in unsere Root View implementieren. ADT und die IDE verweisen auf eine fehlende Freigabe des Views, obwohl dieser eigentlich freigegeben ist.
Test
Zum Abschluss testen wir die neue Implementierung. Da wir unsere bisherige manuelle Logik auskommentiert haben, muss nun die neue Logik übernehmen. Dazu gehen wir in unsere Anwendung, legen einen neuen Datensatz an, ändern diesen und löschen ihn zum Abschluss wieder. Für den Test lassen wir wieder unsere Klasse ZCL_BS_DEMO_RAP_SALES_CHANGE laufen und erhalten alle Änderungen des heutigen Tages. Hier sehen wir, dass die verschiedenen Datensätze korrekt angelegt wurden. Wir haben anschließend den Partner und den Währungsbetrag geändert, genau dort, wo das Update-Flag (U) gesetzt ist. Zum Schluss haben wir den gesamten Datensatz gelöscht. Die Änderungen wurden automatisch vom System übernommen, ohne dass wir eine manuelle Implementierung vornehmen mussten. Daher ist diese Vorgehensweise absolut zu empfehlen, da sie deutlich schneller und weniger fehleranfällig ist als die manuelle Umsetzung.
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
Mit dem passenden Release sind die Änderungsdokumente einfach in die Anwendung integriert. Wie die verschiedenen Einstellungen zu setzen sind, solltest du dir daher einmal im Detail anschauen.
Quelle:
SAP Help - Enable Change Document Integration
ABAP Doc - Changedocument
ABAP Doc - Changedocument (Options)
