Rollen und Berechtigungen

Berechtigungsfehler auswerten

Der Tab Berechtigungen liest den Mitschnitt der OData-Konsole mit; er fragt die Seite nicht noch einmal und sendet nichts. Sobald ein Request mit 401, 403 oder einer SAP-Meldung zu Berechtigung, Service-Aktivierung oder System-Alias zurückkommt, erscheint ein Befund. Gleiche Befunde fasst der Tab zusammen und zählt sie.

1. Öffne in den DevTools (F12) das Panel FrontTailor und wähle den Tab Berechtigungen.
2. Löse in der App die Aktion aus, die scheitert.
3. Lies im Befund das fehlende Objekt mit Feld und Wert und folge den nächsten Schritten.
4. Gib den Befund mit Als Markdown kopieren oder Ticket anlegen… an die Basis weiter.

1. Der Befund: Art, Request, Service, fehlendes Objekt, Meldungscode, Transaktions-ID, Meldung und letzter Zeitpunkt.
2. Nächste Schritte mit Links wie SU53 öffnen und /IWFND/ERROR_LOG öffnen. Sie öffnen SAP GUI for HTML desselben Systems – erst auf Klick.
3. Als Markdown kopieren und Herunterladen (.md) – pro Befund oder für alle.
4. Ticket anlegen… öffnet den Ticket-Dialog des Issue Reporters mit dem Befund, etwa für ServiceNow.

Erkannt werden Standardobjekte wie S_SERVICE und S_START und benannte Objekte („authorization object Z_PRODUCT“), dazu Feld und Wert („activity 03“ wird zu ACTVT = 03) und genannte PFCG-Rollen. Ausgewertet werden JSON (OData V2 und V4), XML und CAP-Fehler, Teile eines $batch einzeln. Benutzerkennungen erscheinen nie im Klartext: DEVELOPER1 wird zu D********1. Exporte enthalten die Seiten-URL ohne Query und Hash.

Warum sehe ich diese Kachel nicht?

Die Prüfkette im selben Tab erklärt, warum eine Kachel im Launchpad fehlt. Weil die Kachel ja nicht zu sehen ist, gibst du ihre Intent ein – Vorschläge kommen aus dem Inhalt des Launchpads; steht eine Intent im aktuellen Hash, ist sie vorbelegt.

1. Öffne den Tab Berechtigungen im Launchpad.
2. Gib unter Intent die Intent ein, etwa SalesOrder-display.
3. Klicke Prüfen. Die Kette läuft Stufe für Stufe; die Zusammenfassung nennt die Stufe, an der die Kachel scheitert.

1. Prüfen startet die Kette für die eingegebene Intent.
2. Die Zusammenfassung, hier: Im Launchpad-Client kein Hindernis gefunden.
3. Stufen, die PFCG- oder SU53-Daten brauchen, sind Nur mit Backend-Service markiert – im Browser wird nicht geraten.

Gibt eine Launchpad-Version eine Information nicht preis, ist die Stufe Unbekannt – nie Gesperrt. Jede Abfrage hat ein Zeitlimit von 10 s. Die Prüfkette läuft nur auf Klick; dabei darf das Launchpad seine eigenen Module und Seiteninhalte nachladen, und läuft die Ziel-App nicht, liest FrontTailor einmal ihre manifest.json vom selben Origin. Für eine sichtbare Kachel ist der Launchpad Inspector das passende Werkzeug.

Rollen-Tab und Backend-Service

Was der Browser nicht wissen kann – PFCG-Rollen, Kataloge der Rolle, Startberechtigung –, liefert das ABAP-Add-on /CDNA/FIORITAILOR, ein lesender OData-V4-Service für S/4HANA on-premise und Private Cloud. Der Tab Rollen schaltet ihn pro Host ein.

1. Öffne die App auf dem SAP-System und im Panel den Tab Rollen.
2. Schalte Backend-Service verwenden ein. Erst jetzt sendet FrontTailor überhaupt Requests an den Service – mit deiner Browser-Sitzung, auf demselben Host.
3. Weicht der Pfad vom Standard ab, trage ihn unter Service-Pfad ein und klicke Übernehmen.
4. Der Zustand wechselt auf Verfügbar; darunter stehen System, Mandant, Benutzer, Add-on, Vertrag und ob du andere Benutzer prüfen darfst.

1. Backend-Service verwenden – gespeichert wird nur dieser Schalter (und ein abweichender Pfad), keine Antworten, keine Benutzer, keine Tokens.
2. Der Zustand des Service.
3. System, Mandant, Benutzer, Add-on, Vertrag, Andere Benutzer prüfen und Service-URL.
4. Benutzer: leer für den eigenen Benutzer, sonst ein anderer.

Ohne Service arbeitet FrontTailor wie bisher; die Stufen „Nur mit Backend-Service“ bleiben offen. Ist der Service verfügbar, nimmt auch Health den ICF-Timeout aus dem System.

Rollen-Simulator: was sieht ein anderer Benutzer?

1. Trage in der Karte Benutzer und Rollen den Benutzer ein. Vor dem Absenden warnt der Tab, dass die Prüfung im Anwendungsprotokoll protokolliert wird.
2. Klicke Anzeigen. Rollen, Kataloge, Spaces, Gruppen und erreichbare Intents erscheinen, jeweils mit der Rolle, die sie zuweist.
3. Klicke eine erreichbare Intent an, um für diesen Benutzer die Prüfkette zu starten – oder gib unten unter Warum sehe ich diese Kachel nicht? eine Intent ein.

1. Der Hinweis vor dem Absenden: Die Prüfung eines anderen Benutzers wird protokolliert (SLG1, Objekt /CDNA/FT).
2. Die Nummer des Protokolls nach der Prüfung.
3. Rollen des Benutzers.
4. Erreichbare Intents mit Filter und zuweisender Rolle.

1. Geprüft für – der simulierte Benutzer.
2. Die Zusammenfassung: Die Kachel scheitert an: Katalog / Inhalt.
3. Startberechtigung mit Service und fehlendem Wert, hier S_SERVICE mit SRV_NAME und SRV_TYPE.

Für einen anderen Benutzer beantwortet das Backend Katalog, Rolle, Target Mapping und Startberechtigung. Kachel auf einer Seite und OData-Service beschreiben nur den Benutzer dieses Browsers und bleiben in der Simulation Unbekannt. Für den eigenen Benutzer nutzt auch der Tab Berechtigungen den Service, sobald er verfügbar ist.

Andere Benutzer prüfen darf nur, wer die Rolle /CDNA/FT_SIM hat (Objekt /CDNA/SIM, Aktivität 03). Jede solche Prüfung schreibt das Add-on vorher in SLG1 – mit Aufrufer, Zielbenutzer und Intent bzw. Service. Kann es den Eintrag nicht speichern, verweigert es die Prüfung.

Typische Probleme