ABAP RESTful & Fiori Elements

ABAP® RESTful & Fiori® Elements: Button in List Reports

Wenn man Anwendungen mit Fiori Elements erstellt, wird man sehr bald mit der Aufgabenstellung konfrontiert, zusätzliche Buttons zu ergänzen. Dies ist mit gewissen Einschränkungen allein durch Erweiterungen im ABAP Backend möglich.

In diesem Beispiel zeige ich, wie man die Buttons in einem List Report mit einer ABAP RESTful Implementierung verwenden kann. Eine Verwendung mit BOPF ist sehr ähnlich und Buttons können auch an anderer Stelle ergänzt werden. Vielleicht schreib ich dazu noch extra einen Blog.

Ich hab dieses Demo auf einem ABAP 1909 Trial und UI5 1.71 System umgesetzt. Es handelt sich um ein unmanaged Szenario, sollte aber ohne großartige Anpassungen auch mit einem managed Szenario funktioineren.

Ausgangssituation

Ich verwende immer sehr vereinfachte, reduzierte Beispiele. Umfangreiches oder schwer nachvollziehbares Coding soll nicht vom eigentlichen Thema ablenken. Obwohl ich ein großer Anhänger von Clean Code und Modern ABAP bin, versuche ich trotzdem in solchen Beispielen so einfach wie möglich zu arbeiten.  Wir haben hier jedenfalls eine Liste von internen Bestellungen und deren Status. Im Detail besteht die Anwendung aus folgenden Objekten. Wenn man eine Anwendung halbwegs sauber aufsetzt, hat man leider so viele Entwicklungsobjekte.

  • ZFOE_DB_ORDER – Order Datenbanktabelle
  • ZFOE_I_ORDER – Order Interface View
  • ZFOE_P_ORDER – Order Projection View
  • ZFOE_P_ORDER – Metadata Extension für Projection View
  • ZFOE_I_ORDER – Behavior Definition Interface View
  • ZBP_FOE_I_ORDER – Behavior Klasse
  • ZFOE_P_ORDER – Behavior Definition Projection View
  • ZFOE_SD_ORDER – Service Definition
  • ZFOE_SB_ORDER – Service Binding

Datenbanktabelle: ZFOE_DB_ORDER

Interface View: ZFOE_I_ORDER

Projection View: ZFOE_P_ORDER

Hier bitte darauf achten, dass die Annotation @Metadata.allowExtensions auf true ist. Dies ist notwendig, um eine Metadata Extension anzulegen.

Metadata Extension: ZFOE_P_ORDER (UI Annotations)

Die Metadata Extension wird verwendet um die UI Annotations besser strukturieren und von den anderen DDLs besser trennen zu können. In dem Beispiel hätten wir die Annotations natürlich auch direkt im Projection View aufnehmen können. Beim Layer ist hier #CORE anzugeben. Die Ausgabeposition der 4 Felder wird hier mit den Annotations @UI.lineItem.position angegeben.

Behavior Definition für ZFOE_I_ORDER

Wir wollen später im Demo lediglich ein update ermöglichen. Daher ist hier update aktiviert. Alles andere kann derzeit deaktiviert bleiben.

Behavior Klasse ZBP_FOE_I_ORDER

In aktuellen Systemen kann die Klasse einfach  über Quick Fix angelegt werden. In älteren Systemen kann das ggf. auch manuell erfolgen.

Behavior Definition für ZFOE_P_ORDER

Service Definition ZFOE_SD_ORDER

Service Bindung ZFOE_SB_ORDER

Und hier noch eine Implementierung um 3 Testdaten in die Tabelle zu schreiben. Das geht super einfach mit dem Interface IF_OO_ADT_CLASSRUN welche in irgendeiner Helperklasse implementiert sein sollte.

So viel zu der Ausgangssituation. Wenn man die Fiori Elements Anwendung nun mit Preview startet, sollte in etwa folgende Liste dargestellt werden:

Button ergänzen

Nun wollen wir uns der eigentlichen Aufgabenstellung widmen und zwei Buttons (Ist die Mehrzahl von Button überhaupt Buttons?) ergänzen. Ein Button soll die Order genehmigen, der zweite Button soll die Order ablehnen. So eine Art Miniworkflow.

Behavior Definitionen & Implementation

Als Erstes müssen wir mal in den Behavior Definitionen von ZFOE_I_ORDER und ZFOE_P_ORDER die beiden neuen Button als Action aufnehmen. Ich hab mich für die Namen but_accept und but_decline entschieden.

In der Behavior Definition ZFOE_I_ORDER geht das ganz einfach durch action gefolgt von einem eindeutigen Namen.  In der Behavior Definition von ZFOE_P_ORDER reicht die Angabe von use und dem Namen der Action.

Natürlich brauchen wir auch später auch eine Methode in unserer Klasse. Über einen Quick Fix auf die action im Interface View kann diese automatisch angelegt werden. Vorerst lassen wir  aber die Methoden einfach leer.

Damit die neuen Buttons auch im Userinterface angezeigt werden, müssen wir zwei Annotations  in der Metadata Extension ZFOE_P_ORDER ergänzen. Dies ist durch eine Erweiterung der lineItem Annotation möglich. Mit type: #FOR_ACTION defineren wir dass es sich um eine Action handelt und in dataAction ist die zuvor angelegt Action anzugeben. Damit wir auch einen Text am Button sehen, sollten wir ein label angeben.

 

Wenn wir uns jetzt die Fiori Anwendung nochmals aktualisieren, sollten die beiden Buttons bereits vorhanden sein:

Wau – das ging ja schnell. Jetzt passiert aber noch nichts wenn man einen der Button klickt. Dafür brauchen wir noch eine Implementierung in den beiden Action-Methoden. Nachfolgendes Coding macht die Änderungen auf der Datenbank. Hinweis: Bitte Verbesserungen am Coding selber machen, für die Demo Zwecke ist die Implementierung vollkommen ausreichend.

Ein neuerlicher Test der Anwendung zeigt uns, dass das Setzen der Statusinformationen bereits funktioniert.

Die Lösung ist bis hierhin schon richtig gut, aber es geht natürlich noch etwas besser. Beispielsweise sollen die beiden Button nur aktiv sein, wenn der Status New ist. Ein bereits gesetzter Status soll nicht mehr verändert werden können.

Button dynamisch aktiv oder inaktiv

Mit den so genannten Instance Features können wir einen Button dynamisch aktiv bzw. inaktiv setzen. Um dies zu erreichen, müssen wir zuerst einmal die Behavior Definition des Interfaces Views etwas anpassen. Der Zusatz ( features: instance ) muss nach action ergänzt werden.

Über die Quick Fix Funktion auf ZFOE_I_ORDER wird auch gleich die neue Methode GET_INSTANCE_FEATURES angelegt. Im nachfolgenden Beispiel lesen wir zuerst mit EML die Entity und setzen in der Export Tabelle den Button auf aktiv oder inaktiv.

Da wir oben mit EML die Entity lesen, sollten wir auch die read Methode implementieren.

Ein erneuter Test sollte nun zeigen, dass die Buttons nur bei Zeilen mit Status „New“ aktiv sind:

Wer es bis hier geschafft hat: Respekt! Ihr habt Euch nun einen Kaffee oder ein Bier verdient.

Button mit Popup

Die zwei Buttons sind ja eigentlich fertig, aber wie wäre es, wenn der Anwender zusätzlich einen Kommentar ergänzen könnte. Geht das einfach? Ja, auch das kann mit Fiori Elements umgesetzt werden.

Zuerst müssen wir eine abstrakte Entität definieren. Die gewünschten Attribute im Popup sind als Felder der Entität anzugeben. Nähere Informationen zu abstract entities bitte bei Bedarf selber nachlesen.

Diese abstrakte Entität müssen wir nun noch in der action der  Behavior Definition des Interface Views eintragen. Mit dem prefix parameter.

Der eingegeben Kommentar soll natürlich auch irgendwie verarbeitet werden. Dafür ist die Implementierung der Action but_decline zu erweitern. Der eingegebene Kommentar befindet sich in der Inbound Struktur keys, Substruktur %param

 

Jetzt noch ein kurzes Stoßgebet und mit etwas Glück funktioniert alles wie gewünscht. Bei Decline erscheint nun ein Popup und die dort eingegeben Message wird zusätzlich zum Status geändert.

Was (noch) nicht möglich ist und was ich vermisse

Alles nur aus Sicht, dass ich keine Anpassung im Frontend (UI5) machen will. Durch individuelle Erweiterungen am Frontend ist natürlich vieles möglicht.

Farben und Icons

Leider können keine Icons oder Farben (Criticality) verwendet werden. Soweit ich gesehen habe ändert sich dies auch in der aktuellsten UI5 Version nicht. Manchmal sind Icons oder Farben einfach hilfreich um wichtige von weniger wichtigen Buttons zu unterscheiden. Ich hoffe, dass SAP dies bald via Annotations ermöglicht.

Es gibt aber die Möglichkeit Emojis oder ASCII-Codes zu verwenden. Damit bekommt man schon Symbole rein. – Im Sinne des Fiori Designs wäre es aber natürlich wichtig die SAP Standard Icons zu untersützten.

Beispiel mit Emojis

Multiline

Action Popups für Multiline List-Reports funktionieren erst ab UI5 1.76. Aufpassen beim Testen. Wenn man z.B. über Visual Studio Code testet, wird meist die aktuellste UI5 Version verwendet. Die Preview Funktion via ADT erzeugt nur eine Anwendung mit Single-Line-Selektion. Bitte immer vorab prüfen, nicht dass dann beim Deployen ins Backend das große Erwachen kommt.

Status & Farben in CDS basierten Fiori Elements Anwendungen

Status & Farben in CDS basierten Fiori® Elements Anwendungen

In Fiori Elements Anwendungen können Statusicons/Statusfarben durch Annotations gesetzt werden. Natürlich auch im CDS View. Dadurch können positive, negative oder neutrale Informationen besonders hervorgehoben werden. Im nachfolgenden Beispiel wird eine textuelle Statusinformation sowohl durch die entsprechende Farbe als auch das passende Symbol hervorgehoben.

 

Umsetzung mit CDS View Annotations

Die Statusinformation muss in einem eigenen CDS Feld vorhanden sein und kann folgende Werte enthalten:

  • 0 Grau
  • 1 Rot
  • 2 Gelb/Orange
  • 3 Grün

Beispielsweise könnte ein Feld StatusColor im CDS View (meist der Interface View) wie folgt gesetzt werden:

Hier wird einfach anhand des Statustextes im Feld _status.Description ein neues Feld StatusColor mit dem entsprechenden Wert gesetzt.

Im Consumption View bzw. In der Metadata Extension ist die Verwendung dann denkbar einfach und durch die UI.lineItem Annotation criticality definierbar:

Durch die zusätzliche Annotation criticalityRepresentation: #WITHOUT_ICON kann die Ausgabe des Icons unterdrückt werden:

Das Ergebnis sieht dann wie folgt aus:

Eine ähnliche Vorgehensweis ist bei vielen anderen Fiori Elements Annotations möglich und z.B. gut über die Codecompletion auffindbar. Beispielsweise bei den Facets oder Feldgruppen.

Ich habe die Farben z.B. in einer Anwendung zur Darstellung von Datenbank Differenzen eingesetzt. Dadurch konnten kritische Abweichungen besonders gekennzeichnet werden.

DDL Source (CDS View) in ADT formatieren

Ab dem Release ABAP 7.51 und den ABAP Development Tools 2.68 gibt es eine Format-Funktion für DDL Source Codes. Es besteht die Möglichkeit sich sein eigenes Profil zu definieren, das  SAP Standardprofil oder ein Teamprofil je Entwicklungspaket zu verwenden.

Formatieren eines DDL Source Code

Das Formatieren eines DDL Source Codes kann wie folgt aufgerufen werden:

  • Shortcut SHIFT + F1
  • Menü bzw. Context Menü: Source Code – Format
  • Automatisch beim Speichern

 

 

 

 

 

 

 

 

 

Formatierungseinstellungen

Die Formatierungseinstellungen können in den Preferences unter ABAP Development – Editors – Source Code Editors – DDL Formatter angepasst werden. Es sind 3 unterschiedliche Gültigkeitsbereiche möglich.

  • SAP Standard Profil – SAP liefert eine nicht veränderbare Voreinstellung aus. Diese steht sofort zur Verfügung.
  • Eigenes Profil – Wenn das Standardprofil nicht ausreicht, kann ein eigenes Profil definiert werden. Eigene Profile können mit der Export- bzw. Import Funktion mit anderen Entwicklern und Systemen ausgetauscht werden.
  • Team Profil – Das SAP Standardprofil kann auf Basis von ABAP Paketen zentral am Server überschrieben werden. Dies ist eine Möglichkeit um unterschiedliche Profile je System oder Paket zu definieren. Technisch erfolgt die Steuerung der Profile im Backend durch eine Implementierung auf den BADI SDDIC_ADT_DDLS_PP_CONF.

Formatierungsdetails

Die Formatierung des DDL Source Codes kann sehr detailliert eingestellt und angepasst werden. Um ein einheitliches Aussehen innerhalb des Systems zu gewährleisten, sollte ein einheitlicher Standard definiert und angewendet werden. Die Verteilung dieser Variante kann entweder über Export/Import erfolgen oder über den oben erwähnten BADI zentral vorbelegt werden.

 

ABAP® CDS Access Control mit DCL

SAP hat mit 7.50 (bzw. die Rede war auch manchmal schon mit 7.40 SP10 – kann ich aber aktuell nicht bestätigen) die CDS Views mit der DCL Data Control Language um die Möglichkeit von impliziten Berechtigungsprüfungen in einem CDS View erweitert. Klingt erstmal etwas trocken ist aber ziemlich genial, denn dadurch können nun Datenbankzugriffe auf Basis der Dateninhalte mit einem Authority-Check versehen werden.

Und das Coole ist, dass dies einfach und schnell erledigt ist!

Nehmen wir an, wir haben eine Tabelle mit ein Feld SOURCE in dem auf der Datenbank die Werte 0001, 0002 und Space vorkommen, im konkreten Fall hab ich einfach die BUT000 genommen wo wir genau solche Einträge vorfinden:

cdsdcl1

Die Idee ist nun, dass wir einen CDS View auf die 4 Felder anlegen und über eine PFCG Rolle steuern dass nur Werte mit der SOURCE 0001 gelesen werden.

CDS View

Zuerst legen wir jetzt mit Eclipse einen neuen CDS View mit der DDL (Data Definition Language) an. Mit den Feldern PARTNER, SOURCE, MC_NAME1 und MC_NAME2:

cdsdcl2

Für jene die noch nicht mit Eclipse gearbeitet haben: DDL und DCL für CDS Views können derzeit nur mit Eclipse bearbeitet werden. Ein persönlicher Tipp: Eclipse wird immer wichtiger. Die CDS Views sind der Anfang. Ohne Eclipse keine CDS Views!

ABAP® CDS Views – 6 Schritte zum Verständnis

DDL Annotations

Natürlich gibt es bei einer DDL Beschreibung viele Annotation-Möglichkeiten, im Hinblick auf eine implizite Berechtigungsprüfung ist auf nachfolgende Annotation zu achten:

@AccessControlauthorizationCheck: #CHECK

die Berechtigungsprüfung durch eine DCL Access Control ermöglicht wird. #CHECK ist der Defaultwert (sprich auch ohne Angabe wäre der Wert auf #CHECK gestellt), weiter Eingabemöglichkeiten sind #NOT_REQUIRED und #NOT_ALLOWED.

  • #CHECK – Eine implizite Berechtigungsprüfung wird vorgenommen. Wenn zu dem View keine DCL existiert, kommt es bei der Syntaxprüfung zu einer Warnung.
  • #NOT_REQUIRED – Gleich wie #CHECK, jedoch ohne Warnung bei der Syntaxprüfung
  • #NOT_ALLOWED – Es wird keine Zugriffskontrolle vorgenommen.

Weitere Informationen zu den DDL Annotations sind bitte der SAP Online Dokumentation zu entnehmen.

PFCG Berechtigungsobjekt

Nun müssen wir ein Berechtigungsobjekt wählen oder neu erstellen. Ich hab ein neues Berechtigungsobjekt ZDEMODCL mit 2 Feldern ZBU_SOURCE und ACTVT erstellt. ZBU_SOURCE steht für den 4stelligen Wert in SOURCE. ACTVT verwende ich um die Aktivität 03 (03 = lesen) abzubilden:

cdsdcl3

DCL Rolle

Als Nächstes erstellen wir mit der DCL (Data Control Language) die Berechtigungsprüfung auf den View. Dazu müssen wir wieder nach Eclipse wechseln und ein DCL Objekt anlegen:

cdsdcl4

Dadurch wird eine DCL Rolle mit dem Namen ZCDSDCLDEMO_NAME definiert. In einer CDS Rolle können eine oder mehrere CDS Entitäten mit CDS Zugriffskontrollen versehen werden. Im konkreten Beispiel wird die CDS Entität ZCDSDEMOENT verwendet. Dies geschieht durch die Angabe GRANT SELECT ON ZCDSDEMOENT.

Nach der Angabe der CDS View muss eine WHERE-Klausel mit der Zugriffsbedingung folgen. Dies kann wiederum als Literalen (z.B. SOURCE = ‘0001‘) bestehen oder wie im obigen Beispiel aus einer PFCG-Bedingung.

PFCG-Bedingung

Eine PFCG-Bedingung wird mit ASPECT PFCG_AUTH ( <authorization_object>, [ field ], [ field ], …. ) definiert. Die Felder der PFCG Bedingung können gemappte Felder aus der WHERE-Klausel oder Literale wie z.B. ‘03‘ sein.

DCL Annotations

Mit der Annotation @MappingRole: true wird die Rolle gegen alle User automatisch geprüft. Weitere Werte sind derzeit hier zum aktuellen Zeitpunkt noch nicht möglich.

Die Annotation @EndUserText.label: ‘zrole_demo‘ ist der übersetzbare Kurztext der Rolle.

Berechtigungszuordnung

Wenn wir die obigen Schritte beendet haben, jedoch noch keine Berechtigungsvergabe an einen User vorgenommen haben, wird dieser bei einem DB Zugriff auf den CDS View – wie erhofft – keinerlei Daten zurückbekommen.

Erst wenn wir dem User eine Berechtigung für das Berechtigungsobjekt Z_DCL_DEMO erteilen werden die erlaubten Daten bei SELECT-Zugriffen zurückgeliefert.

cdsdcl5

SELECT Zugriff auf CDS Entity und CDS DB View

Bei allen ABAP SELECT Zugriffen auf die CDS Entität erfolgt nun die implizite Berechtigungsprüfung. Hingegen bei der obsoleten Möglichkeit des Zugriffs auf den CDS DB View erfolgt diese implizite Prüfung nicht. Aus dem Grund sollten die CDS DB Views auch nicht mehr verwendet werden und wurden von SAP auch als obsolet gekennzeichnet.

Nachfolgend ein Auswertungsergebnis auf ein die CDS Entität (links) und den CDS DB View (rechts). Wie erwartet wurde die Ergebnismenge der CDS Entität implizit auf die SOURCE 0001 gefiltert.

cdsdcl6

Troubleshooting & Testing

Manchmal schlagen sich Änderungen in den DCL Objekten nicht „durch“. Für DCL Analysen kann die Transaktion SACMDCLS verwendet werden. Dort sieht man detaillierte Informationen zu einem DCL Objekt und kann ggf. DCL Artefakte neu generieren.

Weiters ist auch noch die Transaktion SACMSEL interessant. Mit der kann der DCL Zugriff getestet werten.

Weiterführende Informationen