023: Recycling-Heroes - Feature Control and Authorization (Contact)

Inhaltsverzeichnis

• Einführung
• Berechtigungsobjekt
• Hilfsklasse
• Verhalten
• Berechtigungen
• Features
• CDS
• IAM App
• Zusammenfassung

Einführung

In dieser Folge schauen wir auf die Berechtigungen unserer Anwendung. Bisher rufen wir die Anwendung auf und erhalten alle Datensätze angezeigt, ebenso funktionieren alle Aktionen mit den Daten. Daher wollen wir nun zuerst einmal die verschiedenen Aktionen einschränken und zum Abschluss auch die Daten.

 

Berechtigungsobjekt

Zuerst einmal brauchen wir ein neues Berechtigungsobjekt für unsere Daten. Über das Kontextmenü im "Project Explorer" können wir nach "Authorization" suchen und erhalten zwei Einträge. Da wir neben der eigentlichen Aktivität auch die Daten pro Typ abgrenzen wollen, müssen wir im ersten Schritt ein neues "Authorization Field" anlegen. Diesem ordnen wir unser Datenelement zu und vergeben einen kurzen Namen. Leider stehen uns immer noch nur 10 Zeichen zur Verfügung. Nach der Anlage des Elements können wir über den Button "Search Help" prüfen, ob unsere Werte korrekt gezogen werden, da wir diese später in der Suchhilfe sehen wollen. Ein Speichern des Objekts reicht hier aus.

Als nächstes legen wir das eigentliche Berechtigungsobjekt im System an und vergeben diesem einen Namen. Auch hier stehen uns nur 10 Zeichen zur Verfügung. Dem Objekt können wir nun auch unser eigenes Berechtigungsfeld zuordnen. Nach der Anlage des neuen Objekts ist bereits das Feld Aktivität eingebunden. Dieses benötigen wir später, um die verschiedenen Aktionen und die Anzeige der Daten einzeln steuern zu können. Verschiedene Aktivitäten werden uns bereits im unteren Teil vorgeschlagen, die wir auch genauso benötigen.

Damit haben wir alles, um die Berechtigungsprüfung und -abgrenzung durchzuführen und können uns nun der eigentlichen Implementierung zuwenden.

 

Hilfsklasse

Erweitern wir dazu unsere Hilfsklasse, um die Funktionen der Berechtigungsprüfung. Dazu wechseln wir in die Hilfsklasse, die wir uns bereits angelegt hatten. Zuerst einmal benötigen wir einen Basistyp für die Aktivität, um im Anschluss Konstanten anzulegen. Damit müssen wir die verschiedenen Möglichkeiten nicht im Coding hart codieren und haben für die verschiedenen Namen sprechende Werte.

Sind wir damit fertig, legen wir uns eine neue Method an, die die Berechtigungen für eine Aktivität und einen Kontakttypen prüft und uns einen booleschen Wert zurückgibt. In der Methode implementieren wir dann die Berechtigungsprüfung gegen unser Berechtigungsobjekt. Aktivität und Typ vergleichen wir gegen die übergebenen Werte und geben das Ergebnis über die Funktion XSDBOOL zurück.

Neben der eigentliche Überprüfung legen wir noch weitere Hilfsmethoden an, um später das Coding überschaubar und einfach zu halten. Dazu benötigen wir weitere Rückgabetypen für neue Methoden. Der erste Typ soll die jeweiligen Berechtigungen für die Anlage für alle Kontakttypen zurückgeben. Der zweite Typ ist für die verschiedenen Aktivitäten zu einem Typen geplant. Deshalb benötigen wir hier alle angelegten Aktivitäten.

Implementieren wir nun die beiden Methoden in der Hilfsklasse. Dabei geben die Methoden den jeweiligen Typen zurück, wobei wir für die verschiedenen Aktionen auch noch den Typen des Kontakts benötigen. Bei den verschiedenen Create Operationen können wir alle Wert hart codieren, da wir nur das Ergebnis der Berechtigungsprüfung benötigen. Die zweite Methode ist recht ähnlich, hier gehen wir aber auf die verschiedenen Aktivitäten und verwenden dabei den übergebenen Typen. Damit erhalten wir aus den beiden Methoden unser Ergebnis, welche Berechtigungen uns zur Verfügung stehen. Nachdem wir den ABAP Cleaner ausgeführt haben, können wir die Klasse aktivieren und sind damit fertig.

 

Verhalten

Nun müssen wir unsere Aktionen noch in der Verhaltensdefinition für die Anpassung vorbereiten. Für die Create Aktion und die verschiedenen Factory Methoden haben wir bereit globale Berechtigungsprüfungen aktiviert, damit steht uns eine Methode in der Verhaltensimplementierung zur Verfügung. Nun aktivieren wir noch das Feature Control auf Aktualisieren, Löschen und Editieren. Da beim Create zum Beispiel noch kein Typ feststeht, ist diese Option Global definiert. Ob ein Datensatz geändert oder gelöscht werden kann, hängt von den Daten des einzelnen Datensatzes ab, also handelt es sich um eine instanzbasierte Aktion. Haben wir das Objekt gespeichert und aktiviert, müssen wir noch eine neue Methode implementieren.

 

Berechtigungen

Zur besseren Übersicht schieben wir die Methode zu den anderen Prüfmethoden und kümmern uns im Anschluss um die Implementierung dieser. Starten wir mit den Berechtigungen und schauen uns die Methode GET_GLOBAL_AUHTORIZATIONS an. Über die Struktur "Requested" wird angefragt, welches Feld gerade überprüft wird. Dazu sollten wir die RESULT Struktur befüllen mit dem entsprechenden Status. Die Rückgabestruktur enthält für die verschiedenen definierten Felder und Aktionen einen Eintrag. Die Struktur wird dynamisch aus der Einstellung der Verhaltensdefinition generiert. Dazu generieren wir uns wieder eine Instanz der Hilfsklasse und lassen uns über unsere neue Methode die Berechtigungen für die Anlage zurückgeben. Im Anschluss prüfen wir dann pro Aktion und wenn keine Berechtigungen vorhanden sind, schränken wir die Berechtigung ein. Hierzu steht uns in der Standardklasse eine Konstantenstruktur zur Verfügung. Im Anschluss können wir die Zeile kopieren und auf die drei Szenarien anpassen.

Testen wir nun die UI und das Verhalten dazu. Öffnen wir dazu die Anwendung und aktualisieren diese noch einmal. Versuchen wir nun eine Create Aktion auszuführen, erhalten wir die Standardmeldung, dass wir keine Berechtigungen zur Ausführung haben. Auch bei der zweiten Aktion sieht es nicht besser aus, daher funktioniert die Abgrenzung der Berechtigungen für uns.

 

Features

Im nächsten Schritt wollen wir das Feature Control implementieren. Hierbei wird das komplette Feature im UI deaktiviert, wenn die entsprechende Bedingung eintritt. Dabei stehen uns in der Methode die Schlüssel der Entitäten zur Verfügung, da wir im Bereich der einzelnen Instanzen unterwegs sind. Grundsätzlich haben wir eine ähnliche Struktur, wie bei den Berechtigungen zur Auswahl. Kopieren wir uns im ersten Schritt wieder unsere Hilfsklasse und verwenden die Instanz, um für die Schlüssel die Einträge zu lesen.

Im Anschluss verarbeiten wir die verschiedenen Datensätze wie gewohnt in einer Schleife. Da wir die Control Flags anpassen, erzeugen wir uns im ersten Schritt einen Eintrag in der Ergebnistabelle und binden den Datensatz an eine Referenz, um die Inhalte in den nächsten Schritten anzupassen. Rufen wir dazu unsere neue Hilfsmethode auf, um die Einstellungen zum aktuellen Typen zu erhalten. Sind für die Aktion keine Berechtigungen vorhanden, dann deaktivieren wir die Aktion über das Control Flag. Im ersten Schritt ist UPDATE und EDIT das gleiche. Der EDIT kommt vom Draft, da wir die eigentliche Aktion im UI blockieren wollen. Das Gleiche wiederholen wir für DELETE, hier benötigen wir aber nur eine Aktion.

Schauen wir uns nun die Aktionen im UI an, dann sehen wir innerhalb des Datensatzes, dass beide Aktionen nicht verfügbar sind. Im List Report können wir ebenfalls Datensätze markieren und die "Delete" Aktion steht nicht zur Verfügung. Damit greifen die Berechtigungen für verschiedene Aktionen.

 

CDS

Da wir nun die Aktionen eingeschränkt haben, nehmen wir uns im letzten Schritt die Core Data Services vor und schränken die angezeigten Daten ein. Dazu definieren wir uns auf dem CDS View ein neues Access Control. Hier können wir erst einmal den gleichen Namen vergeben, wie für den Core Data Service. Als Template verwenden wir mit "PFCG" Aspekt, da wir eine klassische Berechtigung implementieren wollen. Dann definieren wir uns die Felder, die wir vom Views für die Berechtigungsprüfung benötigen. Hier benötigen wir den Typen des Kontaktes. In der Klammer definieren wir dann das Berechtigungsobjekt und die Berechtigungsfelder in der Reihenfolge, wie sie mit den Feldern des CDS Views matchen. Zum Abschluss definieren wir die Felder, denen wir fixe Werte zuordnen, wie die Aktivität mit 03 für Anzeige.

Nach der Aktivierung können wir über das Kontextmenü den Preview der Daten anzeigen und sehen dort keine Daten mehr, da wir keine zugeordnete Berechtigung haben. Damit wurde die Abgrenzung erfolgreich implementiert. Rufen wir dagegen den Preview auf Consumption Ebene auf, dann erhalten wir wieder alle Daten, da wir auf dieser Ebene keine Prüfung haben und das Access Control nicht automatisch vererbt wird.

Daher legen wir für den Consumption View ebenfalls eine Berechtigungsprüfung an. Der Name bleibt hier ebenfalls der Gleiche, wie der View. Dabei verwenden wir nicht das PFCG Template, sondern das Template, wo wir die Berechtigungen vom Interface Layer erben. Damit müssen wir die Ausprägung nur einmal implementieren und können diese auf den oberen Ebenen weiterverwenden. Damit solltest du nun im Data Preview auch keine Datensätze mehr sehen.

 

IAM App

Gehen wir noch einmal ins UI und laden die Datensätze, es werden nun auch hier keine Informationen mehr angezeigt. Wollen wir einen neuen Datensatz anlegen, dann erhalten wir auch die entsprechende Fehlermeldung vom System.

Der einfachste Weg uns nun die entsprechende Berechtigung zu geben, ist über die IAM App. Dort können wir definieren, welche Berechtigungen wir automatisch erhalten, wenn wir auch diese Kachel bzw. Anwendung haben. In der IAM App wechseln wir auf den Reiter "Authorizations" und können dort direkt Berechtigungsobjekte zuordnen. Daher suchen wir nach unserem Objekt und fügen es hinzu. Als Berechtigung vergeben wir alle Aktionen, bis auf Löschen und Ordnen uns selbst die Berechtigung für die Mitarbeiter zu. Nach dem Speichern können wir über "Publish Locally" die neuen Berechtigungen ins Launchpad propagieren, was eine Weile dauern kann.

Zum Abschluss gehen wir für den Test ins Launchpad und versuchen die Daten noch einmal zu laden. Wir sehen nun alle Mitarbeiter, aber sonst keine anderen Datensätze. Versuchen wir eine neue Adresse anzulegen, erhalten wir weiterhin eine Fehlermeldung. Navigieren wir nun in einen Datensatz, dann sehen wir, dass der Edit Button aktiv ist, wir aber keine Berechtigung zum Löschen des Datensatzes haben. Zum Abschluss versuchen wir noch einen neuen Mitarbeiter anzulegen, womit wir nun in den entsprechenden Dialog kommen.

 

Zusammenfassung

In dieser Folge haben wir uns das Thema Berechtigungen angeschaut, ein neues Berechtigungsobjekt angelegt und uns Schritt für Schritt in den Berechtigungen eingeschränkt. Zum Abschluss hatten wir geprüft, ob wir mit den passenden Berechtigungen auch wieder mit der Anwendung arbeiten können.

Damit sind wir am Ende, danke fürs Zuschauen und bis zum nächsten Mal.

 

YouTube
Video