Im ABAP-Berechtigungstrace über die Transaktion STAUTHTRACE erscheinen mitunter sogenannte CDS-Entitäten, deren Interpretation sich evtl. nicht sofort erschließt. Außerdem kann es passieren, dass die Ergebnisliste einer Auswertung nicht vollständig ist, obwohl laut Berechtigungstrace kein erkennbarer Berechtigungsfehler vorliegt.
Der nachfolgende Artikel wird den technischen Hintergrund dieser „Phänomene“ beleuchten und somit die vielleicht letzte Wissenslücke im SAP-Berechtigungswesen schließen 😊.
Was ist eigentlich eine CDS-View
Über eine View werden grundsätzlich Zugriffe auf ausgewählte Daten aus definierten einzelnen Tabellen oder Tabellen-Joins ermöglicht. Diese muss zunächst in einer entsprechenden Entwicklungsumgebung erstellt werden.
Eine CDS-View (Core Data Services View) ist eine erweiterte Datenbank-View, die in SAP S/4HANA und ABAP verwendet wird. Ihre Entwicklung erfolgt außerhalb der klassischen ABAP-Umgebung (z. B. über das ABAP Developer Tool (ADT) in Eclipse), daher kann sie mit der Bearbeitungstransaktion SE11 für Dictionary-Objekte im ABAP-Stack nicht bearbeitet, sondern nur angezeigt werden. Ein Vorteil der CDS-Views besteht darin, dass die Datenselektion bereits in der HANA Datenbank und somit wesentlich performanter durchgeführt wird.
Zunächst einmal ist hier zu unterscheiden zwischen der DDL Source, der CDS View und der DDL SQL View:
In der DDL Source enthalten ist die eigentliche Definition der CDS-View. In ihr werden u. a. die Namen der CDS View und einer zugehörigen DDL SQL View (kurz: SQL View) definiert. Im Gegensatz zur CDS View kann auf die SQL View später über die klassischen Tabellenanzeige Transaktionen wie etwa SE16 oder SE16N zugegriffen werden.
Der Zusammenhang lässt sich an einem Beispiel der SQL View ISDSALESORDER in der Transaktion SE11 verdeutlichen.
Zu sehen ist hier die SQL View ISDSALESORDER mit der zugehörigen DDL Source, welche die eigentliche Definition der Views enthält, die zugrundeliegende „Tabelle“ mit Selektionsbedingung und die Fehlermeldung bei dem Versuch, die View in der Transaktion zu ändern.
Die Anzeige der SQL View ISDSALESORDER und der „Tabelle“ ISDSALESDOC (es handelt sich hier eigentlich auch um eine SQL View) mit der angezeigten Selektion in der TA SE16 sollte also das gleiche Ergebnis liefern.
Mit einem Doppelklick auf den Namen der DDL Source kann deren Inhalt angezeigt werden. Hier ist beispielsweise neben diversen anderen Metadaten die eigentliche Definition der CDS View zu sehen, auf die zwar nicht über die TA SE16, aber durch Reports o. ä. zugegriffen werden kann. In diesem Fall heißt sie genauso wie die DDL Source I_SalesOrder.
Weiterhin ist hier die Definition der SQL View ISDSALESORDER zu erkennen, und aus Berechtigungssicht ist der Eintrag „authorizationCheck: #CHECK“ interessant, da somit Berechtigungsprüfungen beim Zugriff auf die CDS-View stattfinden.
Über das Menü HILFSMITTEL – OBJEKTLISTE ANZEIGEN wird der Repository-Browser geöffnet, über den u. a. die in der View-Definition enthaltenen Berechtigungsprüfungen ersichtlich sind.
Berechtigungstrace für verschiedene Zugriffswege auf die CDS-View
Zunächst werden die Daten über die zugehörige SQL View über die TA SE16 angezeigt.
Wie zu erwarten war, wird in diesem Fall auf die klassischen Berechtigungsobjekte für Tabellenzugriffe, in diesem Fall über das Objekt S_TABU_NAM auf den Namen der SQL View ISDSALESORDER geprüft.
Im zweiten Fall soll auf die CDS View direkt zugegriffen werden. Da dies nicht mit Transaktionen wie der SE16 funktioniert, wurde ein kleines ABAP-Programm geschrieben:
Erwartungsgemäß wird bei der Ausführung die bereits bekannte Anzahl an Datensätzen ausgegeben.
Der Berechtigungstrace stellt sich jetzt komplett anders dar, da hier die Berechtigungsprüfungen aus der CDS View durchgeführt wurden.
Was passiert nun, wenn dem Endbenutzer Berechtigungen entzogen werden?
Zunächst wird das Objekt V_VBAK_VKO komplett deaktiviert.
Die Auswertung wird trotzdem ohne Fehlermeldung für den Endanwender durchgeführt, aber es werden keine Daten ausgegeben.
Nur über den Berechtigungstrace wird nachvollziehbar, dass hier in Wirklichkeit eine fehlende Berechtigung für die leere Ergebnismenge verantwortlich war.
Interessanter wird es, wenn die Berechtigungen beispielsweise auf dem Objekt V_VBAK_VKO nicht komplett deaktiviert, sondern nur eingeschränkt werden.
Der Endanwender bekommt nur die berechtigten Elemente angezeigt.
Weder der Ergebnisliste noch dem Berechtigungstrace lässt sich nun entnehmen, dass die Daten aufgrund der vergebenen Berechtigungen nur im eingeschränkten Umfang ausgegeben werden. Der Trace sieht exakt so aus, wie bei einer Vollberechtigung.
Fazit
Falls es vorkommen sollte, dass bei irgendeinem geplagten Endanwender aus unerfindlichen Gründen weniger Daten angezeigt werden als erwartet, und der Berechtigungstrace aber keine fehlenden Berechtigungen anzeigt, dann schauen Sie doch einmal genauer, ob nicht vielleicht eine Zugriffsfilterung über eine CDS View stattgefunden hat. Im Zweifelsfalle müssten Sie diese Berechtigungen bei dem betroffenen Endanwender genauer analysieren (oder einfach mal SAP_ALL zuordnen 😊).
Evtl. existiert zu der im Trace gefundenen „CDS-Entität“ auch eine SQL View, über die man mit entsprechenden Tabellen-Berechtigungen eine Gegenprobe mit der kompletten Datenmenge machen kann. Hierbei kann die Tabelle DDHEADANNO helfen.
