Berechtigungen in SAP NetWeaver BW - ReadingSample · In SAP NetWeaver BW gibt es unterschiedliche Arten von Berechtigungen. Sie haben gemeinsam, dass sie – sinnvoll implementiert

SAP PRESS

Berechtigungen in SAP NetWeaver BW

Bearbeitet vonPeter John, Peter Kiener

erweitert 2012. Buch. ca. 676 S. HardcoverISBN 978 3 8362 1870 2

Format (B x L): 16 x 24 cm

Weitere Fachgebiete > EDV, Informatik > Datenbanken, Informationssicherheit,Geschäftssoftware > SAP

schnell und portofrei erhältlich bei

Die Online-Fachbuchhandlung beck-shop.de ist spezialisiert auf Fachbücher, insbesondere Recht, Steuern und Wirtschaft.Im Sortiment finden Sie alle Medien (Bücher, Zeitschriften, CDs, eBooks, etc.) aller Verlage. Ergänzt wird das Programmdurch Services wie Neuerscheinungsdienst oder Zusammenstellungen von Büchern zu Sonderpreisen. Der Shop führt mehr

als 8 Millionen Produkte.

http://www.beck-shop.de/John-Kiener-Berechtigungen-SAP-NetWeaver-BW/productview.aspx?product=10155813&utm_source=pdf&utm_medium=clickthru_lp&utm_campaign=pdf_10155813&campaign=pdf/10155813http://www.beck-shop.de/trefferliste.aspx?toc=8249http://www.beck-shop.de/trefferliste.aspx?toc=8249

Bonn � Boston

Peter John, Peter Kiener

Berechtigungen in SAP NetWeaver BW®

1870.book Seite 3 Freitag, 4. Mai 2012 9:35 09

Auf einen Blick

1 Analyseberechtigungen für Einsteiger: eine praktische Einführung ................................................. 23

2 Berechtigungskonfiguration ............................................... 107

3 Standardberechtigungen in SAP NetWeaver BW .............. 201

4 Analyse von Berechtigungsprüfungen und -konfiguration .............................................................. 249

5 Anforderungsprofile und Lösungsansätze typischer Berechtigungsmodelle in BW ............................................. 303

6 Berechtigungsmodelle für Reporting und Planung ............ 357

7 Performance ........................................................................ 457

8 Migration ............................................................................ 477

9 Analyseberechtigungen für Experten .................................. 523

10 Berechtigungen im SAP BusinessObjects Explorer ............ 599

11 SAP NetWeaver BW-Berechtigungen und die SAP BusinessObjects Business Intelligence Platform ........ 615

A FAQ ..................................................................................... 635

B Wichtige DataStore-Objekte für die Generierung ............. 639

C Anleitung – Implementierung derBeispiele aus Kapitel 6 ....................................................... 645

D Die Autoren ......................................................................... 661


7

Inhalt

Vorwort .................................................................................................... 15

Einleitung ................................................................................................. 17

Für Anwender ohne viele Vorkenntnisse in den Bereichen Berechtigungen und SAP NetWeaver BW ist es reizvoll, zu ersten Ergebnissen zu kommen, ohne die gesamte Komplexität der Analyseberechtigungen erfassen zu müssen. Dieses Kapitel führt Sie zügig und Schritt für Schritt zu typischen Anwendungsbeispielen am System. 23

1 Analyseberechtigungen für Einsteiger: eine praktische Einführung ................................................. 23

1.1 OLAP und Datenberechtigungen ........................................... 231.1.1 Vergleich des Berechtigungswesens in

OLAP-Systemen und in OLTP-Systemen .................... 241.1.2 Berechtigungswesen in SAP NetWeaver BW ............. 251.1.3 Vorlagebenutzer, Rolle und Profil .............................. 25

1.2 Erste Schritte mit Analyseberechtigungen .............................. 341.2.1 Überblick – Benutzer, Query und Berechtigung

anlegen ..................................................................... 361.2.2 Merkmale berechtigungsrelevant machen ................. 371.2.3 Berechtigung anlegen ............................................... 391.2.4 Query anlegen .......................................................... 431.2.5 Zuordnung zu Benutzern ........................................... 44

1.3 Ausführung und Fehleranalyse ............................................... 451.3.1 Ausführung für eingeschränkte Benutzer ................... 451.3.2 Erste Fehleranalyse mit dem Protokoll

und Korrektur ........................................................... 471.3.3 Leitsätze der Analyseberechtigungen ......................... 53

1.4 Möglichkeiten der Analyseberechtigungen ............................ 561.4.1 Variablen gefüllt aus Berechtigungen ........................ 561.4.2 Aggregationsberechtigung ........................................ 591.4.3 Hierarchieberechtigungen ......................................... 621.4.4 Mehrdimensionale Berechtigungen ........................... 731.4.5 Klammerung ............................................................. 831.4.6 Teilweise Maskierung ................................................ 911.4.7 Anzeigeattribute und Navigationsattribute ................ 100

1.5 Zusammenfassung und Fazit .................................................. 105

Die Infrastruktur der Analyseberechtigungen bietet eine Fülle hilfreicher Transaktionen, Oberflächen und Funktionen zur effektiven Konfiguration und Verwaltung. Dieses Kapitel zeigt Ihnen die vielfältigen Möglichkeiten. 107

2 Berechtigungskonfiguration ............................................... 107

2.1 Transaktionsüberblick ............................................................ 1072.2 Die Berechtigungsadministration

(Transaktion RSECADMIN) .................................................... 108


Inhalt

8

2.2.1 Die drei Hauptfunktionen ......................................... 1092.2.2 Berechtigungsprüfungen für Aktivitäten innerhalb

der Transaktion RSECADMIN .................................... 1122.2.3 Menü »Zusätze« ........................................................ 1152.2.4 Berechtigungsrelevanz von Merkmalen

konfigurieren ............................................................ 1172.3 Berechtigungspflege .............................................................. 118

2.3.1 Übersicht über die Merkmalsberechtigungen ............ 1192.3.2 Detailpflege – Werteberechtigungen ......................... 1292.3.3 Universalberechtigung 0BI_ALL ................................. 1412.3.4 Detailpflege – Hierarchieknoten-Berechtigungen........ 142

2.4 Berechtigungspflege mit SAP NetWeaver BW 7.3 .................. 1532.4.1 Analytics Security Objects und Versionen .................. 1532.4.2 Berechtigungspflege .................................................. 1542.4.3 Transport .................................................................. 155

2.5 Benutzerzuordnung ............................................................... 1562.5.1 BW-eigene Zuordnung über die Transaktion RSU01... 1572.5.2 Integration in das SAP-Rollenkonzept ....................... 1612.5.3 0BI_ALL und SAP_ALL .............................................. 163

2.6 Massengenerierung von Analyseberechtigungen .................... 1652.6.1 Content-Vorlagen für die Generierung ...................... 1662.6.2 Verwendung der Generierung ................................... 1682.6.3 Beispiel-Anwendungen für die Generierung .............. 1692.6.4 Hinweise zur Benutzung ............................................ 185

2.7 SAP NetWeaver BW 7.3 – Massenpflege und Informationssystem ............................................................... 1862.7.1 Massenpflege Berechtigungen ................................... 1872.7.2 Massenpflege mit Benutzern ..................................... 1972.7.3 Fazit zur Massenpflege .............................................. 199

In SAP NetWeaver BW gibt es unterschiedliche Arten von Berechtigungen. Sie haben gemeinsam, dass sie – sinnvoll implementiert – eine dauerhaft stabile Anwendung für Benutzer und Support bieten. Den Teil der BW-spezifischen Berechtigungen abseits der Analyseberechtigungen beschreiben wir in diesem Kapitel. 201

3 Standardberechtigungen in SAP NetWeaver BW .............. 201

3.1 Grundlagen ........................................................................... 2013.2 Technische Eigenschaften der Berechtigungsobjekte .............. 2043.3 Datenmodellierung und allgemeine Berechtigungen .............. 208

3.3.1 SAP ERP-Quellsystem ............................................... 2103.3.2 SAP NetWeaver BW – Datenmodellierung ................ 214

3.4 Die wichtigsten Berechtigungsobjekte im Reporting .............. 2273.4.1 Arbeiten mit BW Querys ........................................... 2273.4.2 Integrierte Planung ................................................... 237


Inhalt

9

3.4.3 Weitere BW-Services (Broadcaster, BEx Web Application Designer, SAP BusinessObjects Dashboards) .............................................................. 240

3.5 Einfluss auf das BW-Berechtigungsmodell .............................. 2423.5.1 Berechtigungsvorlagen und SAP-Standardrollen ......... 2423.5.2 Berechtigungsadministration ..................................... 246

3.6 Fazit ...................................................................................... 248

4 Analyse von Berechtigungsprüfungen und -konfiguration .............................................................. 249

4.1 Ausführen »als eingeschränkter Benutzer« .............................. 2504.1.1 Transaktion RSUDO und Sicherheitsaspekte .............. 2524.1.2 Probleme mit Benutzername »sy-uname« im

User-Exit ................................................................... 2544.2 Das Berechtigungsprotokoll ................................................... 256

4.2.1 Protokollverwaltung .................................................. 2564.2.2 Protokollaufbau ........................................................ 2584.2.3 Protokollkopf ............................................................ 2604.2.4 Wertehilfen und Variablen ........................................ 2614.2.5 Prüfungsbestandteile ................................................ 2664.2.6 Optimierungen ......................................................... 2854.2.7 Archivierung ............................................................. 292

4.3 Changelog ............................................................................. 2944.3.1 Tabellen und Inhalte ................................................. 2954.3.2 Reporting und Audit mit BW-eigenen Mitteln............ 296

4.4 Klassische Berechtigungsprotokolle ....................................... 2994.5 Fazit ...................................................................................... 302

Vier Augen sehen mehr als zwei – das sollten Sie bei der Definition eines Berechtigungsmodells beherzigen und möglichst einfache, beständige und wartbare Modelle entwickeln. Wie Sie das machen, erfahren Sie in diesem Kapitel. 303

5 Anforderungsprofile und Lösungsansätze typischer Berechtigungsmodelle in BW ............................................. 303

5.1 Das Berechtigungsmodell im BW-Projekt ............................... 3045.1.1 Vorüberlegungen ...................................................... 3055.1.2 Berechtigungsmodell – Beginn .................................. 3085.1.3 Ausschließlich Standardberechtigungen oder

Analyseberechtigungen? ........................................... 3115.1.4 Namensräume ........................................................... 3125.1.5 Berechtigungsrelevante Merkmale ............................ 3155.1.6 Analyseberechtigungen zuordnen ............................. 320

5.2 Grundmodelle der Standardberechtigungen ........................... 3255.2.1 Einteilung der Benutzertypen .................................... 325


Inhalt

10

5.2.2 Verwendung von Vorlagen ........................................ 3265.2.3 Das Rollenmodell ...................................................... 3285.2.4 Zentralberechtigungsrolle für alle Benutzer ............... 3305.2.5 Umgang mit bestehenden Standardberechtigungen ... 3315.2.6 Aufwände für ein reines Standardberechtigungs-

modell ...................................................................... 3315.3 Generische Modellansätze ..................................................... 332

5.3.1 InfoProvider-basiertes Modell ................................... 3335.3.2 InfoObject-basiertes Modell ...................................... 3355.3.3 Mischformen ............................................................. 3365.3.4 Zusammenfassung der generischen Modelle .............. 3375.3.5 Spezialfall integrierte Planung ................................... 3435.3.6 Bestehende Modelle anpassen bzw. erweitern ........... 345

5.4 Operative Modelle bzw. Customizing-Modelle ...................... 3465.4.1 Variablenbasierte Modelle ........................................ 3465.4.2 Generierungsbasierte Modelle ................................... 351

5.5 Fazit ...................................................................................... 356

Nach der Theorie geht es nun wieder in die Praxis. Wie implementieren Sie sauber und effektiv zuvor entwickelte Berechtigungsmodelle? Darüber wird Ihnen dieses Kapitel Aufschluss geben. 357

6 Berechtigungsmodelle für Reporting und Planung ............ 357

6.1 Überblick über die Anwendungsmodelle ............................... 3586.2 Modell 1 – Standardberechtigungen ...................................... 361

6.2.1 Vorlagen und Datenmodell erstellen ......................... 3626.2.2 Vor- und Nachteile des Modells – Fazit ..................... 392

6.3 Modell 2 – variablenbasierte Analyseberechtigungen ............. 3936.3.1 Standard- in Analyseberechtigungen umgestalten ...... 3936.3.2 Navigationsattribute und Klammerung einbinden ...... 3976.3.3 Problemfälle bei mehrdimensionalen

Berechtigungen ......................................................... 4036.3.4 Exit-Lösungsvorschlag bei mehrdimensionalen

Berechtigungen ......................................................... 4076.3.5 Hierarchien, Zeitabhängigkeit und Exit-Variablen ....... 4146.3.6 Vor- und Nachteile des Modells – Fazit ..................... 434

6.4 Modell 3 – generierungsbasierte Analyseberechtigungen ....... 4346.4.1 Analyseberechtigungen definieren ............................. 4366.4.2 DSOs für die Generierung bereitstellen und füllen...... 4386.4.3 Generierung ausführen und kontrollieren .................. 4426.4.4 Vor- und Nachteile des Modells – Fazit ..................... 444

6.5 Modell 4 – Analyseberechtigungen undBW-Integrierte Planung ......................................................... 4456.5.1 Das Planungsmodell .................................................. 4456.5.2 Standardberechtigungen für die Planung erweitern .... 446


Inhalt

11

6.5.3 Query für die Planung definieren .............................. 4476.5.4 Test der Berechtigungen in der Planung .................... 4506.5.5 Exkurs – Customer-Exit für Variablen ......................... 4516.5.6 Vor- und Nachteile des Modells – Fazit ..................... 455

Die Berechtigungsprüfung sollte generell nicht zeitintensiv sein. Wie Sie Probleme bei der Modellierung vermeiden und bestehende Probleme beheben, erfahren Sie in diesem Kapitel zur Performance bei der Berechtigungsprüfung. 457

7 Performance ........................................................................ 457

7.1 Ablauf der Berechtigungsprüfung ........................................... 4587.2 Ungeeignete Modellierung .................................................... 459

7.2.1 Viele kleine Berechtigungen mit wenig Inhalt ............ 4597.2.2 Zeitintensiv zu mischende Berechtigungen ................ 463

7.3 Ungeeignete Selektionen ....................................................... 4677.3.1 Selektion der Query .................................................. 4677.3.2 Auflösung von Hierarchien ........................................ 468

7.4 Customer-Exit ........................................................................ 4697.4.1 Verwendung der Pufferung ....................................... 4707.4.2 Performance innerhalb des Customer-Exits ............... 4717.4.3 Ungünstige Wertübergabe ........................................ 472

7.5 Fazit ...................................................................................... 475

Analyseberechtigungen sind nach einem Upgrade auf SAP NetWeaver BW 7.0 oder höher verfügbar. Damit sie genutzt werden können, müssen bestehende Berechtigungskonzepte überarbeitet und entsprechend migriert werden. 477

8 Migration ............................................................................. 477

8.1 Grundlagen ........................................................................... 4788.2 Vergleich von altem und neuem Berechtigungskonzept ......... 4788.3 Vorbereitung und Analyse ..................................................... 483

8.3.1 Berechtigungsrelevante Merkmale ............................ 4848.3.2 Liste der RSR-Berechtigungsobjekte .......................... 4858.3.3 Das Prüfungsverhalten im System .............................. 4868.3.4 Identifizieren der kritischen Reporting-

anwendungen ........................................................... 4878.4 Aufbau des Migrationskonzeptes ........................................... 487

8.4.1 Übersicht über das bestehende Berechtigungsmodell ................................................ 488

8.4.2 Gesamtmigration der Reportingberechtigungen ......... 4898.4.3 Teilmigration oder Neuaufbau ................................... 4908.4.4 Migration ohne InfoProvider ..................................... 4978.4.5 Nacharbeiten bei einer automatisierten Migration ..... 4978.4.6 Zusammenführen mehrerer

RSR-Berechtigungsobjekte ........................................ 4988.4.7 Migration von generierungsbasierten Modellen ......... 4988.4.8 Berechtigungsrelevante InfoObjects, die unter

BW 3.x nicht geprüft wurden .................................... 498


Inhalt

12

8.4.9 Migrationsaufwand für Standard-Berechtigungsmodelle ............................................... 500

8.4.10 Das Backup-Szenario ................................................. 5018.4.11 Zusammenfassung der Migrationsmöglichkeiten ........ 501

8.5 Halbautomatische Migration von SAP BW 3.x aufSAP NetWeaver BW 7.x ......................................................... 5028.5.1 Grundlegende Hinweise zur Migration ...................... 5028.5.2 Beispielaufbau einer Migration .................................. 5028.5.3 Schritt 1 – Start des Wizards und Auswahl

der Benutzer ............................................................. 5068.5.4 Schritt 2 – Berechtigungsobjekte ............................... 5068.5.5 Schritt 3 – Zuordnungsmethode ................................ 5078.5.6 Schritt 4 – Detailkonfiguration .................................. 5098.5.7 Ergebnis und Auswertung ......................................... 512

8.6 Migration von SAP BW 3.x auf SAP NetWeaver BW 7.3 ........ 5188.7 Migration von SAP NetWeaver BW 7.0 auf

SAP NetWeaver BW 7.3 ........................................................ 5198.8 Fazit ...................................................................................... 520

Beleuchten wir nun spezielle Eigenschaften der Analyseberechtigungen in Kombination mit anderen BW-Funktionen. Dabei werden wir viele Detailfragen aus der Praxis behandeln, die beim Kunden speziellere Lösungen erfordern. Sie erfahren hier auch, was im Zusammenspiel mit anderen Features möglich ist. 523

9 Analyseberechtigungen für Experten .................................. 523

9.1 Herangehensweise ................................................................. 5249.2 Werteberechtigungen ............................................................ 524

9.2.1 Bedeutung der Intervalle in SAP NetWeaver BW........ 5249.2.2 Funktionsumfang in Analyseberechtigungen .............. 527

9.3 Hierarchieberechtigungen ...................................................... 5349.3.1 Funktionsumfang ...................................................... 5349.3.2 Automatische Filterung ............................................. 5419.3.3 Winterlandschaften ................................................... 5439.3.4 Wechselwirkung mit Werteberechtigungen ............... 5449.3.5 Zeitabhängigkeit ....................................................... 5509.3.6 Temporaler Hierarchie-Join ....................................... 5559.3.7 Nicht eindeutige Hierarchien .................................... 5589.3.8 Intervallhierarchien ................................................... 5619.3.9 Fazit .......................................................................... 565

9.4 Klammerung in Berechtigungen ............................................. 5659.4.1 Einfache Klammerung ............................................... 5669.4.2 Gemischte Berechtigungen, Mehrfachklammerung,

Grenzen .................................................................... 5759.5 Zusammenfassung und Optimierung von Berechtigungen ...... 577

9.5.1 Grundprinzip ............................................................. 577


Inhalt

13

9.5.2 Kombination – Verallgemeinerung ............................ 5799.5.3 Vereinfachen (Mischen) von Berechtigungen ............. 5809.5.4 Vollständige Optimierung ......................................... 5849.5.5 Generalisierung auf beliebig viele Dimensionen ......... 585

9.6 Ablauf-Optimierungen ........................................................... 5899.7 Integrierte Planung ................................................................ 5909.8 Variablen, Exits und BAdIs ..................................................... 591

9.8.1 Variablen in Berechtigungen ..................................... 5929.8.2 Das BAdI für virtuelle Berechtigungen mit

SAP NetWeaver BW 7.3 ............................................ 5939.9 Fazit ...................................................................................... 597

In diesem Kapitel werden wir einen Ausflug in die Welt des SAP BusinessObjects Explorers machen. 599

10 Berechtigungen im SAP BusinessObjects Explorer ............ 599

10.1 Replikation aus SAP NetWeaver BW ...................................... 59910.2 Ergebnis im Explorer – Einschränkungen ................................ 60410.3 Benutzergruppen ................................................................... 61110.4 Diskussion und Fazit .............................................................. 612

Die neue SAP BusinessObjects Business Intelligence-Plattform dient als Brücke zwischen den Welten des SAP NetWeaver Business Warehouse und SAP BusinessObjects Business Intelligence. Wir werden nun in diesem Zusammenhang den Problemkreis Berechtigungen auf der SAP BusinessObjects BI-Plattform beleuchten. 615

11 SAP NetWeaver BW-Berechtigungen und dieSAP BusinessObjects Business Intelligence Platform ........ 615

11.1 Central Management Console (CMC) ..................................... 61611.1.1 Anbindung an SAP NetWeaver BW ........................... 61711.1.2 Synchronisation von Rollen und Benutzern ............... 618

11.2 Organisation der Zugriffsberechtigungen in der Central Management Console ................................................ 623

11.3 Einbindung einer BW Query in eine SAP BusinessObjects BI-Anwendung ...................................................................... 628

11.4 Zusammenfassung und Fazit .................................................. 631

Anhang ...................................................................................... 633

A FAQ ................................................................................................. 635B Wichtige DataStore-Objekte für die Generierung ............................. 639C Anleitung – Implementierung der Beispiele aus Kapitel 6 ................. 645D Die Autoren ..................................................................................... 661

Index ...................................................................................................... 663


17

Einleitung

Security ist ein Thema von ständig wachsender Bedeutung. Die Datensicher-heit in Business-Intelligence-Software ist da keine Ausnahme. Im Gegenteil,besteht hier doch seit geraumer Zeit schon Bedarf an angemessenen Sicher-heitsmechanismen zum Schutz der Daten, die oftmals aus dem gesamtenUnternehmen zusammengeführt werden. Diese Daten sind aus unterschied-lichen Gründen sehr sensibel und müssen abzusichern sein, ohne das ganzeSystem abzuschließen.

Business-Intelligence-Software wie SAP NetWeaver Business Warehouse(BW) bietet dynamische Sichten auf die multidimensionale Datenhaltung.Oftmals sind die Anforderungen an die Sicherheit dergestalt, dass die Datenin einer Sicht verfügbar sein sollen, in anderen Sichten jedoch nicht. Die Sich-ten auf die Daten werden interaktiv durch den Anwender verändert. Dasunterscheidet die Sicherheitsanforderungen von denen für transaktionaleSysteme, für die die Zugriffsberechtigungen anders gebaut sein müssen undtypischerweise einmalige Zugriffsberechtigungen sind.

Wir werden in diesem Buch beide Welten diskutieren, da es natürlich auchbeide Welten in BW gibt. Die transaktionale Welt der Berechtigungen wirdabgebildet durch Berechtigungsobjekte. Die multidimensionale Welt wird inSAP NetWeaver BW durch die Analyseberechtigungen abgebildet, die die frü-heren Reportingberechtigungen ablösen.

Motivation für das Buch

Die Gründe für die Entstehung dieses Buches sind vielfältig. Es ist das Ergeb-nis einer ganzen Reihe von Erfahrungen und Erlebnissen der Autoren mitden Berechtigungen im SAP-Umfeld und insbesondere mit den besondersleistungsfähigen und deshalb auch umfangreichen Berechtigungen in SAPNetWeaver BW. Aus verschiedenen Quellen sind Erfahrungen und Rückmel-dungen von Anwendern in das Buch eingegangen.

Ganz konkret gehen viele Inhalte des Buches auf eine Vielzahl von Kunden-meldungen zurück, auf Gespräche mit Supportmitarbeitern, Kollegen von derRIG, der Beratung, der SAP-internen Verwendung sowie auf den Austauschmit Kunden auf Konferenzen. Ebenso ist die Erfahrung, die bei der Imple-


Einleitung

18

mentierung von Berechtigungsmodellen oder bei der Optimierung von beste-henden Modellen erworben wurde, in dieses Buch mit eingeflossen.

Die Historie zeigt, dass viele Mitarbeiter ganz unverhofft in die Verantwor-tung für die Berechtigung stolpern, ohne dass sie große Vorkenntnisse besit-zen. Da man bei OLAP-Berechtigungen häufig nicht an die Unterschiede zutransaktionalen Berechtigungen denkt, kann es vorkommen, dass Mitarbeiterder SAP-Basis die Verantwortung für BW-Berechtigungen erben, da siebereits transaktionale Berechtigungen betreuen. Natürlich gibt es aber auchden Experten für SAP-Berechtigungen und vielleicht auch für die Reporting-berechtigungen, der nun die Analyseberechtigungen kennenlernen will.

Wir möchten in diesem Buch beide Enden des Spektrums ansprechen, denAnfänger wie den Experten. Deshalb haben wir die vorliegende Formgewählt.

In vielen Fragen der Beratung wünscht man sich endlich einmal genügendZeit und Raum für ausführlichere Erklärungen und Beispiele, die die eigent-liche Dokumentation sprengen würden. In Reaktionen auf Kundenmeldun-gen spricht man immer nur einen kleinen Ausschnitt des Themenkomplexesan, noch dazu spezifisch auf das ganz konkrete Problem zugeschnitten. Des-wegen sind Antworten aus der Beratung nicht wiederverwendbar, um ande-ren Kunden zu helfen, die ähnliche Probleme haben. Anders verhält es sichmit diesem Buch: Es können zwar nicht alle Spezialfälle und Probleme abge-deckt werden, doch sollte es mit Hilfe des Buches möglich sein, bestehendeModelle bei Problemen entsprechend zu optimieren bzw. einen richtigenAnsatz bei Neuimplementierungen zu wählen.

Ein weiterer wichtiger Punkt ist, dass reine Beratung nicht Bestandteil desStandardsupports ist. Die meisten Probleme in puncto Berechtigungen stellenallerdings Verständnisschwierigkeiten oder ungeeignete Implementierungendar und nicht Software-Fehler von SAP NetWeaver BW. Deshalb kam schonvor Jahren der Gedanke auf, ein Buch mit ausführlichen Erklärungen und Bei-spielen zu allen relevanten Themen zu schreiben. Nach anfänglichen Versu-chen im Alleingang durch Peter John ist es uns nun im Zweierteam mit PeterKiener erfolgreich gelungen, das Projekt umzusetzen.

Wir hoffen, mit diesem Buch viele Nutzer anzusprechen und möglichst vielenSAP NetWeaver BW-Berechtigungsprojekten zum Erfolg zu verhelfen.


Einleitung

19

Inhalt

Im Anschluss an diese Einleitung finden Sie in Kapitel 1, »Analyseberechtigun-gen für Einsteiger: eine praktische Einführung«, ein spezielles Kapitel fürAnfänger im Bereich Berechtigungen, die einen guten Überblick über dieMöglichkeiten der Analyseberechtigungen bekommen möchten. Aber auchder Kenner wird in diesem Kapitel mit Sicherheit noch Neues entdecken.

Kapitel 2, »Berechtigungskonfiguration«, beschäftigt sich mit den Transaktio-nen und Benutzeroberflächen im Umfeld der Analyseberechtigungen. Hierfinden sich Details, die über Kapitel 2 hinausgehen.

Kapitel 3, »Standardberechtigungen in SAP NetWeaver BW«, beschreibt dieStandardberechtigungsobjekte und ihre Anwendung in SAP NetWeaver BW.Für einen verantwortlichen Projektleiter oder Berater gehören sie zu denGrundlagen.

Kapitel 4, »Analyse von Berechtigungsprüfungen und -konfiguration«, erläutertdie Analysemöglichkeiten der Berechtigungen. Das Berechtigungsprotokollder Analyseberechtigungen nimmt den größten Raum ein, da es sehr vieleDetails enthalten kann.

Kapitel 5, »Anforderungsprofile und Lösungsansätze typischer Berechtigungsmo-delle in BW«, hilft, den Teil der Berechtigungen innerhalb eines SAP NetWea-ver BW-Projekts umzusetzen. Es werden die unterschiedlichen Modelle derStandard- und Analyseberechtigungen besprochen und deren Realisierungim System gezeigt.

Kapitel 6, »Berechtigungsmodelle für Reporting und Planung«, beschäftigt sichmit der Praxis. Auf Basis der bereits erworbenen Kenntnisse werden nununterschiedliche Berechtigungsszenarien implementiert, und dabei wirdnochmals die Theorie wiederholt. Die Modelle reichen von reinen Standard-berechtigungen bis hin zum Einsatz komplexerer Analyseberechtigungsmo-delle. Sie haben hier die Möglichkeit, parallel zum Buch die Beispiele selbstim System zu implementieren. Es steht entsprechender Demo-Content zumDownload unter www.sap-press.de bereit. Wie Sie auf diesen Content zugrei-fen und ihn nutzen können, erfahren Sie in Anhang C.

Kapitel 7, »Performance«, beschäftigt sich mit dem Thema Performance undBerechtigungen. Es werden die typischen Performance-Fallen im Zusammen-hang mit Analyseberechtigungen dargestellt, und Sie erfahren, wie Sie diesevermeiden können.


Einleitung

20

Kapitel 8, »Migration«, beschäftigt sich mit dem Thema Migration, ausge-hend vom alten Ansatz der Reportingberechtigungen. Hier werden die mög-lichen Szenarien für eine Migration – wie ein kompletter oder teilweiser Neu-aufbau der Analyseberechtigungen im Vergleich zu der vom Systemunterstützten Migration – vorgestellt und verglichen.

Kapitel 9, »Analyseberechtigungen für Experten«, ist ein Kapitel für Expertenund solche, die es werden wollen. Es beschäftigt sich mit den speziellerenFeatures der Berechtigungen im Zusammenspiel mit anderen hochkomple-xen Bereichen wie Hierarchien, Zeitabhängigkeit, Klammerung und der Opti-mierung der Berechtigungen, die aber geradezu zwangsläufig in der Praxisauftauchen und für Verwirrung sorgen können.

Kapitel 10, »Berechtigungen im SAP BusinessObjects Explorer«, zeigt, wieBerechtigungen mit dem SAP BusinessObjects Explorer funktionieren und inwelchem Zusammenhang sie mit SAP NetWeaver BW stehen.

Kapitel 11, »SAP NetWeaver BW-Berechtigungen und die SAP BusinessObjectsBusiness Intelligence Platform«, beschäftigt sich mit den Berechtigungen fürdie BusinessObjects BI-Plattform und der Anbindung von SAP NetWeaverBW-Systemen.

Im Anhang des Buches werden einige der häufigsten Fragen beantwortet, diesich jeder schon einmal gestellt hat, der im Umfeld von Berechtigungen arbei-tet (Anhang A). Der Anhang enthält außerdem die in Kapitel 2, »Berechti-gungskonfiguration«, beschriebenen Generierungsobjekte und die Regeln fürdie Kombination (Anhang B) sowie die für Kapitel 6, »Berechtigungsmodellefür Reporting und Planung«, benötigten Informationen, um die Datenmo-delle mit Hilfe des Demo-Contents selbst im System umsetzen und parallelzum Buch arbeiten zu können (Anhang C).

Motivation und Entstehung der Analyseberechtigungen

SAP NetWeaver BW ist nach der Anfangszeit recht schnell gewachsen undsehr erfolgreich auch in den größten Firmen der Welt eingesetzt worden.Dabei ist das Konzept der Reportingberechtigungen mitgewachsen und hatsein Korsett eigentlich schon lange gesprengt. Die Anforderungen an einDatensicherheitskonzept lassen sich nur sehr unzulänglich mit den normaler-weise üblichen Berechtigungsobjekten des SAP-Konzepts abbilden. Deshalbwurde zu Beginn der Entwicklung von SAP NetWeaver 7.0 entschieden,einen neuen Ansatz zu versuchen, der einer multidimensionalen OLAP-Welt


Danksagung

21

angemessener ist als die Berechtigungsobjekte. Zahlreiche Beschränkungender Berechtigungsobjekte konnten bei der Neukonzeption beseitigt unddurch viel allgemeinere Konzepte ersetzt werden, die genau auf BW zuge-schnitten sind.

Das war ein großer Sprung im Gegensatz zur vorangegangenen evolutionärenEntwicklung. Das neue Rahmenwerk der Analyseberechtigungen hat sich alsextrem erfolgreich für Nutzbarkeit, Wartung, Flexibilität und Erweiterbarkeitherausgestellt. Und bis heute hat kein Kunde bereut, den Sprung zum neuenKonzept gemacht zu haben, auch wenn dieser einen gewissen Initialaufwandbedeutete.

Eine Reihe von speziellen Workshops mit der DSAG (Deutschsprachige SAP-Anwendergruppe) zum Thema BW-Berechtigungen in der frühen Entwick-lungsphase ermöglichte einen fruchtbaren Austausch zwischen Anwendernund der Entwicklung bei SAP. Diese Erfahrungen haben unmittelbaren Ein-gang in die Fortentwicklung der Analyseberechtigungen gefunden.

Danksagung

Wir möchten hier den Kollegen danken, die in den vergangenen Jahren mit-geholfen haben, die neuen Analyseberechtigungen zu einem Erfolg zumachen, allen voran Clemens Rother, dem ehemaligen unermüdlichenBerechtigungsexperten in der IMS. Besonderer Dank gilt auch den WienerKollegen im Global Support Center Österreich, besonders Peter Stockinger,der beiden Autoren ein wichtiger, immer geduldiger Ansprechpartner warund ist.

Christoph Lenschow und Maxim Kulakov möchten wir für Hinweise undUnterstützung bei der Überarbeitung der ersten Auflage danken.

Ebenso möchten wir uns besonders bei der Red Rooster IT GmbH in Wienfür ihre Zeit und Ressourcen bedanken. Wir hoffen, dass ihr kompetenterInput zu täglichen Herausforderungen der Beratungspraxis diesem Buchzusätzliche Relevanz und Praxisnähe verleiht.

Peter John und Peter Kiener


303

Vier Augen sehen mehr als zwei – das sollten Sie bei der Definition eines Berechtigungsmodells beherzigen und möglichst einfache, beständige und wartbare Modelle entwickeln. Wie Sie das machen, erfahren Sie in diesem Kapitel.

5 Anforderungsprofile und Lösungs-ansätze typischer Berechtigungs-modelle in BW

Mit jeder Implementierung eines BW-Projekts muss man sich auch Gedan-ken über die zu vergebenden Berechtigungen machen. Der Grund hierfür istnicht zwangsläufig, dass die Daten des Modells so sensibel sind. Es ist ein-fach eine Vorgabe des Systems, Berechtigungen zu vergeben, um den Benut-zern das Reporting zu ermöglichen. In diesem Kapitel werden wir uns nunim Detail mit dem Ablauf der Konzeptionierung und Realisierung einesBerechtigungsmodells beschäftigen. Zuerst wollen wir die Begriffe Berechti-gungsmodell und Berechtigungskonzept erläutern.

Wir werden nun im Folgenden den Ablauf eines Projekts und den dazugehöri-gen Aufbau eines Berechtigungsmodells im Detail entwerfen. Womit beginntman bei der Konzeptionierung? Welche Merkmale schaltet man berechti-gungsrelevant? Welchen Modellansatz sollte man wählen? Diese Fragestellun-gen versuchen wir innerhalb dieses Abschnitts zu beantworten. Mit Hilfe vonChecklisten können Sie sich einen Überblick verschaffen, um die Komplexitätzu bewerten und gegebenenfalls auf ein Mindestmaß zu reduzieren.

Berechtigungsmodell und Berechtigungskonzept

Ein Berechtigungsmodell enthält den Aufbau der berechtigungsrelevanten Merk-male eines Datenmodells, der Merkmalswert-Selektion (wenn Analyseberechti-gungen eingesetzt werden) und der Berechtigungsdefinition sowie der Berechti-gungsvergabe. Auf einem BW-System kann es mehrere voneinander unabhängigeBerechtigungsmodelle geben.

Ein Berechtigungskonzept kann ein oder mehrere Berechtigungsmodelle enthal-ten. Es kann aber auch für das gesamte System gelten.


Anforderungsprofile und Lösungsansätze5

304

Danach beschäftigen wir uns mit Standardberechtigungen, die ein Teil jedesBW-Projekts sind. Wir gehen auf die Bedeutung von Namensraumkonzeptenund die Verwendung von Vorlagen für Standardberechtigungen ein.

Im Anschluss stellen wir unterschiedliche Ansätze für Analyseberechtigungs-modelle vor: Wir besprechen zunächst die Arten der Modelle und beschäfti-gen uns mit dazu passenden Fragestellungen. Wann und wie können Info-Provider- oder InfoObject-basierte Modelle zum Einsatz kommen? Wie gehtman mit einer bestehenden Berechtigungsinfrastruktur um, die für neueAnforderungen erweitert werden muss? Anschließend werden wir uns auchdie Techniken und Möglichkeiten für die Implementierung des Analysebe-rechtigungsmodells im System ansehen. Beginnen wir nun damit, uns denAblauf eines BW-Projekts und ein dazugehöriges Berechtigungskonzeptanzusehen.

5.1 Das Berechtigungsmodell im BW-Projekt

Das Ziel einer Berechtigungslösung sollte immer sein, die Daten ausreichendzu schützen und den Benutzern die zugestandenen Sichten zu ermöglichen.Ebenso wichtig ist es aber auch, das Modell für etwaige Erweiterungen flexi-bel zu halten und möglichst wartungsfreundlich aufzubauen. Es ist nahezuunmöglich, vor allen zukünftigen Anforderungen und damit verbundenenÄnderungen gefeit zu sein. Bei neuen Anforderungen an das Reporting,organisatorischen oder rechtlichen Anpassungen werden teilweise auch dieKonzepte überarbeitet und adaptiert werden müssen. Und das sollte mög-lichst problemlos erfolgen.

Bei BW-Projekten kann es durchaus der Fall sein, dass kurz vor dem geplan-ten Go-live der Applikation festgestellt wird, dass die Benutzer zu vieleBerechtigungen haben und nicht nur die für sie bestimmten Zahlen zu sehenbekommen. Das bedeutet nicht notwendigerweise, dass im Projekt bei der

Keep it secure and as simple as possible!

Diesen Leitspruch sollte man bei der Entwicklung von Berechtigungsmodellenimmer im Hinterkopf haben. Ziel eines Berechtigungsmodells muss es sein, dieDaten nach den Vorgaben zu schützen, jedoch den Benutzern entsprechendberechtigte Sichten zu gewähren. Für die Realisierung im System ist es wichtig,nicht zu komplexe und wartungsunfreundliche Modelle aufzubauen. Die Anforde-rungen an ein Berechtigungsmodell machen es möglich, eine passende Lösungauszuarbeiten und umzusetzen.


Das Berechtigungsmodell im BW-Projekt 5.1

305

Implementierung schlecht gearbeitet wurde. Vielmehr haben die unter-schiedlichen Parteien, die bei einem Projekt mitwirken, abweichende Erwar-tungen:

Einem Mitarbeiter einer Fachabteilung mag es eigenartig erscheinen, dassman Berechtigungen nicht einfach schnell anpassen und zuordnen kann. Daer diese Anpassung als unproblematisch empfindet, wird er seine Ände-rungswünsche möglicherweise erst kurz vor dem Go-live vorbringen. Even-tuell bringt er auch noch Änderungswünsche bezüglich eines Merkmals an,das bis dato noch gar nicht im Blickfeld für Berechtigungen war.

Um nicht solchen Missverständnissen zu erliegen und das Projekt zeitge-recht abschließen zu können, muss die Problematik der Berechtigungenrechtzeitig bei der Planung bedacht, berücksichtigt und mit den Fachabtei-lungen besprochen werden. Denn gerade Berechtigungen sind ein sensiblerBereich und führen rasch zu einer zeitlichen Verschiebung, wenn sie nicht zu100 % wasserdicht, getestet und abgenommen sind. Wir wollen uns nun imWeiteren damit beschäftigen, wie der Ablauf eines BW-Projekts unter derBeteiligung der Berechtigungen aussehen sollte.

5.1.1 Vorüberlegungen

Zu Beginn eines jeden Projekts steht der Wunsch nach bestimmten Sichtenauf Kennzahlen, die relevant sind, um ein Unternehmen aktuell oder zukünf-tig steuern zu können – unabhängig davon, ob es der tägliche Produktions-ausstoß, eine quartalsweise Ergebnisrechnung oder die Budgetplanung fürdie kommenden fünf Jahre ist. Relevante Kennzahlen sollen einer Gruppevon Benutzern zur Verfügung gestellt werden.

Nachdem geklärt ist, welche Benutzergruppen wie auf welche Kennzahlenzugreifen können sollen, wird man beginnen, ein entsprechendes Projektmit einem dazugehörigen Projektplan aufzusetzen.

Abbildung 5.1 zeigt auf der linken Hälfte, wie so ein einfacher Plan für einBW-Projekt aussehen kann:

Umgang mit bestehenden Berechtigungsmodellen

Wenn bereits ein BW-Berechtigungsmodell mit einem dazugehörigen Berechti-gungsmodell besteht, kann nicht von null an neu geplant werden. Existierenbereits bestehende Berechtigungen, müssen diese berücksichtigt werden und indas neue Konzept einfließen. In den späteren Abschnitten dieses Kapitels gehenwir noch auf den Umgang mit bestehenden Berechtigungsmodellen ein.



306

1. Zu Beginn müssen Umfang, Inhalt und zeitlicher Rahmen bestimmt wer-den. Auf dieser Basis wird ein Konzept erstellt, das noch nicht bis inskleinste Detail der Realisierung ausgefeilt ist. Jedoch sollte daraus schonhervorgehen, welche Benutzergruppen auf welche Datenbasis zugreifenwerden 1.

Abbildung 5.1 Ablauf eines BW- und Berechtigungsprojekts

2. Damit kann nun die Phase der Feinplanung beginnen 2. Wir nennen siedetaillierte Modellentwicklung: In dieser Phase muss zunächst genau spezi-fiziert werden, wie der Datenfluss in BW auszusehen hat, welche InfoPro-vider und Merkmale verwendet werden und wie man die Daten denBenutzern tatsächlich zugänglich macht – über Querys, Arbeitsmappenoder weitere Frontend-Produkte.

1

BW-Projekt

Phase der Konzepterstellung

DetaillierteModellentwicklung

Realisierung am System

Testen des realisierten Datenmodells

Go-live der Applikation

Berechtigungsteil

DetaillierteModellentwicklung

Realisierung am System

Testen des realisierten Berechtigungsmodells

Phase der Konzepterstellung



307

3. Danach folgt die Implementierung im System selbst 3.

4. Ist die Implementierung abgeschlossen, kann man die Daten und in wei-terer Folge die Berichte testen 4. Bekanntlich gibt es in dieser Phaseimmer wieder Anpassungen, die man am Modell vornehmen muss, weilzusätzliche Anforderungen gewünscht werden oder das geplante Ergebnisnicht erzielt werden konnte.

� Es sollte dann eigentlich nur an der Implementierung Veränderungengeben.

� Ist es aber nicht möglich, diese so weit anzupassen, dass die Änderun-gen durchgeführt werden können, kann es vorkommen, dass mannochmals einen Schritt zurückgehen und Teilbereiche der Realisierungneu überdenken muss.

5. Letztendlich kommt der befreiende Go-live, und die Benutzer können dieBerichte produktiv verwenden 5.

Wie sieht es nun mit den Berechtigungen während des Projektablaufs aus?

Wie Sie auf der rechten Seite der Abbildung 5.1 sehen, sollte man rechtzeitigin der Phase der Konzepterstellung auch schon die Berechtigungen beden-ken. Während der Phase der Feinkonzeptionierung bietet es sich an, dieBerechtigungen mit ins Boot zu nehmen und ein Konzept für diese zu erstel-len 6. Man muss sich vor Augen halten, was das Berechtigungskonzept allesabdecken muss:

� Rollenkonzept für Standardberechtigungen

� Menürollen für Berichtsbereitstellung

� Berechtigungskonzept für selbständige Berichtsentwicklung

� Analyseberechtigungen für den Zugriff auf Bewegungsdaten

Je komplexer das Datenmodell wird – wie etwa durch eine große Anzahl vonInfoProvidern, auf denen aktiv Reporting stattfindet –, desto umfangreicherwird auch das Berechtigungsmodell 7. Aus diesem Grunde ist es durchausnotwendig, in dieser Phase bereits an alle Aspekte, also auch an die Berech-tigungen, der Projektimplementierung zu denken.

Sind einmal die weitere Vorgehensweise und die Realisierung beschlossen,können Berechtigungen sehr gut parallel zum restlichen Projekt implemen-tiert werden 8. Anschließend folgt auch hier der Test 9. Alle Phasen, vomAufbau im System bis hin zum Testen, können parallel abgearbeitet werden,wenn genügend Ressourcen für die Realisierung zur Verfügung stehen.



308

Als Nächstes wollen wir uns ansehen, wie man ein Berechtigungsmodellerstellt. Wo beginnt man, und was muss alles bedacht werden?

5.1.2 Berechtigungsmodell – Beginn

Haben Sie einen Überblick über das gesamte Datenmodell und den Benutzer-kreis, können Sie daran gehen, sich ein Berechtigungsmodell zu überlegen.Die Vorgaben für Berechtigungen kommen meist aus der Fachabteilungselbst. Sie gibt an, wer zum Benutzerkreis gehört und wie die Benutzer von-einander abgegrenzt werden sollen. Die Angaben können nicht immer 1:1im System umgesetzt werden. Auf jeden Fall bieten sie aber den Einstiegs-punkt, um innerhalb des Projekts gemeinsam eine Lösung zu erarbeiten, wiedie Berechtigungen aufgebaut sein müssen.

Welches sind die Fragen, die man sich und den Mitgliedern des Projektteamsin dieser Phase stellen muss? Wir haben diese Fragen in der folgenden Auf-zählung lediglich grob in zwei unterschiedlichen Themenblöcken zusam-mengefasst:

� Benutzergruppen/StandardrollenkonzeptBezüglich des Rollenkonzeptes sollten Sie sich folgende Fragen stellen:

� Wie viele Benutzer werden das Reporting verwenden?

� Gibt es nur standardisierte Berichte oder auch von Benutzern selbster-stellte?

� Dürfen Berichte von Benutzern in der produktiven Umgebung selbsterstellt werden?

� Welche Benutzer dürfen selbst Berichte erstellen?

� Dürfen Standardberichte auch von Reportingbenutzern geändert wer-den? Davon ist jedoch abzuraten.

Änderungen von Standardberichten durch Benutzer

Standardberichte werden vordefiniert und mit dem Go-live eines Projekts an dieBenutzer ausgerollt. Somit erwarten die Benutzer, dass die Berichte immer iden-tisch aussehen und »korrekte« Zahlen liefern. Werden diese Standardberichte nunvon einem Benutzer mit Änderungsberechtigungen abgeändert, sollte diese Aktionmit allen Benutzern, die diese Berichte verwenden, abgesprochen werden, um nie-manden zu verwirren.

Von solch einer funktionierenden Kommunikation ist aber nicht auszugehen, des-halb sollten die Benutzer keine Standardberichte ändern, sondern diese nur kopie-ren und unter neuem Namen speichern dürfen.



309

� Auf welchen InfoProvidern dürfen welche Benutzer Berichte erstellen,wenn mehrere Reporting-InfoProvider im Datenmodell vorkommen?

� Kann man den Benutzern, wenn sie unterschiedliche Berichte sehendürfen, diese nur über ein Rollenmenü zugänglich machen?

� DatenberechtigungenBezüglich der Datenberechtigungen sollten Sie sich folgende Fragen stellen:

� Dürfen alle Benutzer alle Daten sehen?

� Welchen Bereich der Daten sollen die einzelnen Benutzer sehen dürfen?

� Wie kann man die Sichten einschränken?

� Ist es notwendig, die Benutzer auf Merkmalsebene zu berechtigen?

� Wird es in absehbarer Zukunft Änderungen am Datenmodell geben,bzw. sind zukünftig Erweiterungen geplant, die auch eine Auswirkungauf Berechtigungen haben?

� Wechseln die Benutzer und/oder deren Berechtigungen häufig?

Sind diese Fragen beantwortet, kann man sich ein besseres Bild davonmachen, welche Anforderungen an das Berechtigungsmodell gestellt werden.Die Informationen können nun grafisch aufbereitet werden; beispielsweisekann man dazu einen Entscheidungsbaum zeichnen – Abbildung 5.2 zeigt eineinfaches Beispiel. Alle Punkte, die abgeklärt worden sind, werden in der kor-rekten Reihenfolge als Entscheidungen eingetragen. Aus der Grafik ergibt sichein kritischer Pfad, über den man letztendlich zu einem Standardberechti-gungs- bzw. Rollenkonzept finden kann. Detaillierte Informationen bezüglichAbbildung 5.2 folgen bei den Modellen für Standardberechtigungen.

In dieser Darstellung haben wir noch keine Analyseberechtigungen mit ein-bezogen, diese werden wir in Abschnitt 5.1.5, »BerechtigungsrelevanteMerkmale«, noch genauer unter die Lupe nehmen.

Einfacher als ein Entscheidungsbaum ist das Zusammenfassen der gesammel-ten Informationen in Form einer Tabelle (siehe Tabelle 5.1). Die Tabelle stellteinen Auszug aus den gesammelten Informationen dar. Die Anforderungenan das Modell werden eingetragen und jeweils mit einem »Ja« oder »Nein«versehen. Diese übersichtliche Darstellung hilft während der Konzeptionie-rung, den Überblick zu behalten und eine entsprechende Entscheidungbezüglich des Modells zu treffen.



310

Abbildung 5.2 Entscheidungsbaum für Standardberechtigungen

Mit der Tabelle haben Sie nun eine gute Zusammenfassung der Anforderun-gen und können mit der Definition eines Berechtigungsmodells beginnen.Wenn Sie auf Basis des Ansatzes »Keep it secure and as simple as possible«arbeiten, ist die nächste logische Konsequenz, dass Sie sich die Frage stellen,ob Sie überhaupt Berechtigungen für das Datenmodell benötigen. Oder nochgenauer formuliert: Benötigen Sie Analyseberechtigungen, oder reicht einStandardberechtigungskonzept?

Anforderungen Ja Nein

Gibt es Berichtsvorlagen? ✔

Erstellen Benutzer selbst Berichte? ✔

Sollen Berichtsersteller auf unterschiedliche InfoProvider berechtigt sein?

✔

Genügt ein Rollenmenü für alle Reportingbenutzer? ✔

Dürfen alle Benutzer alle Daten sehen? ✔

…

Tabelle 5.1 Anforderungen an ein Standardberechtigungskonzept

Stan

dard

bere

chti

gung

enR

olle

nmod

ell

Berechtigungsmodell

NeinJa

Nur Vorlageberichte?

Separate Menürolle?

Ja Nein

Eine RolleZwei Rollen

Unterteilung in Berichtsersteller und Reportingbenutzer?

Ja Nein

Power-User-RolleVerteilte Rollen und Menürolle?

Ja Nein

Zwei RollenDrei Rollen



311

5.1.3 Ausschließlich Standardberechtigungen oder Analyseberechtigungen?

In Kapitel 3, »Standardberechtigungen in SAP NetWeaver BW«, wurden dieStandardberechtigungen besprochen. Auf diese kann man bei keinem BW-Projekt verzichten – egal ob es um die Implementierung oder das Reportinggeht, alle Benutzertypen brauchen sie. Mit den Analyseberechtigungen ver-hält es sich etwas anders. Datenmodelle in BW enthalten unterschiedlichsensible Daten. Ein Bestandsreporting auf Lagerbestände ist weniger sensi-bel als beispielsweise Zahlen der HR-Abteilung. Daraus ergibt sich die Not-wendigkeit zu prüfen, ob man die Benutzer auf die Inhalte entsprechendberechtigen muss oder ob es ausreichend ist, mit Standardberechtigungen zuarbeiten.

Unterschiedliche Einflussfaktoren sind zu beachten: Es kann sein, dass dieFachabteilung bestimmte Sichten für Benutzer fordert. Möglich sind auchorganisatorische oder rechtliche Vorgaben. Diese müssen eingehalten wer-den. Am Projektteam liegt es dann zu prüfen, ob die Anforderungen mitStandard- oder Analyseberechtigungen umgesetzt werden können.

Der Vorteil eines Standardberechtigungskonzeptes ist die geringere Komplexi-tät. Die Einschränkung erfolgt auf Berichtsebene auf den technischen Namender Query. Das ist leichter verständlich und erfordert weniger Kenntnisse inBW. Dadurch werden vermutlich die Aufwände für Wartung und etwaigeÄnderungen niedriger gehalten als bei einem Analyseberechtigungskonzept.

Nachteilig wirkt sich die erhöhte Anzahl an Rollen und auch Berichten aus:Angenommen, ein Unternehmen ist in zwei Ländern tätig, dann müssen dieQuerys für jedes Land fix eingeschränkt werden. Somit ergeben sich zweiQuerys mit unterschiedlichen technischen Namen, je eine, die fix auf einLand eingeschränkt ist. Um die Querys den Benutzern im Reporting bereit-zustellen, wird man eine Menürolle verwenden. Man kann dafür entwedereine oder zwei Menürollen erstellen. Bei den Menürollen können zusätzlichOrdner verwendet werden, die Benutzer zu ihren Querys leiten, wie esAbbildung 5.3 zeigt.

Fassen wir nochmals die Vor- und Nachteile eines reinen Standardberechti-gungskonzeptes im Vergleich zu den Analyseberechtigungen in Tabelle 5.2zusammen.

Wie man sieht, ist es absolut sinnvoll, sich Gedanken zu machen, »welches«Konzept man implementieren soll. Es hat direkt Auswirkung auf die Auf-wände der Konzeptionierung, Implementierung und Wartung des Berechti-



312

gungsmodells. Nun wollen wir aber mit einem ganz wichtigen Erfolgsfaktorfür jedes BW-System weitermachen, den Namensräumen.

Abbildung 5.3 Landesspezifisches Rollenmenü in der PFCG

5.1.4 Namensräume

Einer der zentralsten Punkte für ein gut funktionierendes BW-System ist einKonzept für Namensräume. Je größer das System wird und je mehr Daten-modelle darauf abgebildet sind, desto wichtiger werden eindeutige Namens-räume. SAP selbst macht dies mit dem Konzept der »führenden Null« beiObjekten, die aus dem Business Content kommen, vor. Jeder Benutzer, derauf einen SAP NetWeaver BW-System arbeitet, weiß sofort, dass es sich hier-bei um Elemente des Contents handelt. Genau das muss auch das Ziel einesNamensraumkonzeptes sein. Es geht darum, schnell Zusammenhänge herzu-stellen und Objekte des Systems zuzuordnen.

Standardberechtigungskonzept Vorteil Nachteil

geringes Maß an Komplexität des Konzeptes ✔

niedrigere Aufwände in der Wartung ✔

Stammdatenänderungen (z.B. bei Hierarchien) ohne Auswirkung auf Berechtigungen

✔

höhere Anzahl an Querys ✔

eventuell erhöhte Anzahl an Rollen ✔

Analyseberechtigungen im Nachhinein einfacher einzuführen

✔

Tabelle 5.2 Vor- und Nachteile eines Konzeptes ohne Analyseberechtigungen


477

Analyseberechtigungen sind nach einem Upgrade auf SAP NetWea-ver BW 7.0 oder höher verfügbar. Damit sie genutzt werden können, müssen bestehende Berechtigungskonzepte überarbeitet und entspre-chend migriert werden.

8 Migration

Wird ein BW-System durch ein Upgrade oder bei einer Neuinstallation aufeine Version höher oder gleich 7.0 gebracht, stehen die Analyseberechtigun-gen zur Verfügung. Dieses Kapitel ist hauptsächlich für BW 3.x-Systeme rele-vant, die durch ein Upgrade auf BW 7.0 oder höhere Versionen gehobenwerden. Wenn mit BW 3.x bereits Reportingberechtigungen (der Vorgängerder Analyseberechtigungen) eingesetzt wurden, können diese Berechtigun-gen migriert werden. Bei der Neuinstallation von BW 7.0 werden vonAnfang an Analyseberechtigungen eingesetzt.

In diesem Kapitel beginnen wir in Abschnitt 8.1, »Grundlagen«, mit einemÜberblick über den Prozess der Migration. In Abschnitt 8.2, »Vergleich vonaltem und neuem Berechtigungskonzept«, werden die beiden BW-Daten-Berechtigungskonzepte für die Versionen 3.x und 7.0 kurz verglichen,anschließend werden wir genauer auf den Prozess der Migration eingehen.Für die Migration gibt es unterschiedliche Ansätze, die wir in Abschnitt 8.4,»Aufbau des Migrationskonzeptes«, vorstellen. Vor jedem Migrationsprozesssollte eine Analyse der bestehenden Berechtigungen erfolgen, um bereitsbekannte Problemfälle – soweit dies möglich ist – zu beheben oder zu opti-mieren bzw. um den Status der Berechtigungen zu ermitteln und damit dieMigration in Angriff zu nehmen. Auf den Prozess der Analyse, die damit ver-bundenen Tätigkeiten und daraus resultierende Ergebnisse gehen wir inAbschnitt 8.3, »Vorbereitung und Analyse«, ein. Gegen Ende des Kapitelsbeschäftigen wir uns in Abschnitt 8.5, »Halbautomatische Migration von SAPBW 3.x auf SAP NetWeaver BW 7.x«, detailliert mit dem zur Verfügunggestellten Migrationstool auf Analyseberechtigungen und den Effekten derMigration von BW 3.x-Systemen auf BW 7.0. Danach werden wir kurz erläu-tern, was man bei Berechtigungsmigrationen auf SAP NetWeaver-Versionenhöher als 7.0 zu beachten hat.


Migration8

478

8.1 Grundlagen

Für die Migration der Berechtigungen gibt es kein vollautomatisiertes Werk-zeug. Es werden immer manuelle Arbeiten benötigt, um auf Analyseberech-tigungen umzustellen. Die Erstellung des Migrationskonzeptes ist natürlichsehr stark von den Implementierungen im System abhängig. Da es die unter-schiedlichsten Varianten gibt, ist es weder sinnvoll noch möglich, einenexakten Leitfaden für alle Möglichkeiten anzubieten. Wir versuchen, grund-legend zu verdeutlichen, worauf man achten muss und welche Möglichkei-ten es für den Umstieg gibt.

Das bereitgestellte Migrationstool bietet die Möglichkeit, die Migration fürBenutzer und Berechtigungsobjekte durchzuführen. Hier besteht eine gegen-seitige Abhängigkeit: Für die Migration gilt der Grundsatz der Vollständig-keit. Das bedeutet: Wenn ein Berechtigungsobjekt selektiert wird, müssendie Berechtigungen aller Benutzer, denen dieses Objekt zugeordnet ist, mi-griert werden. Das System prüft diese Abhängigkeit vor der Migration undgibt im Fall von fehlenden Benutzern eine entsprechende Meldung aus. Da-rauf ist bei der Erstellung des Konzeptes zu achten, um nicht bei der Migra-tion selbst überrascht zu werden. Auch die Standardobjekte für InfoProvi-der, wie z.B. S_RS_MPRO, werden nach dem Prinzip der Vollständigkeitbehandelt. Daher ist es schwierig, auf ein bestimmtes Reportingberechti-gungsobjekt einzuschränken, wenn man InfoProvider-Berechtigungen mitRSR-Reportingberechtigungsobjekten migriert. Automatisch müssen auchalle Benutzer, denen das InfoProvider-Berechtigungsobjekt zugeordnet ist,migriert werden.

Betrachten wir nun die beiden unterschiedlichen Berechtigungskonzepte fürSAP BW 3.x und SAP NetWeaver BW 7.0.

8.2 Vergleich von altem und neuem Berechtigungskonzept

Die SAP NetWeaver BW-Releases vor 7.0 setzten das Konzept der sogenann-ten Reportingberechtigungen ein. Dieses Konzept basiert ebenfalls auf berech-tigungsrelevanten Merkmalen, hatte aber im Vergleich zu den Analyseberech-tigungen einige Restriktionen: Bei den Reportingberechtigungen mussteneigene Berechtigungsobjekte angelegt werden, wie Abbildung 8.1 zeigt. DieseBerechtigungsobjekte wurden der Objektklasse RSR zugeordnet. Die Klassenvon Berechtigungsobjekten sind bereits aus Abschnitt 3.2, »Technische Eigen-


Vergleich von altem und neuem Berechtigungskonzept 8.2

479

schaften der Berechtigungsobjekte«, bekannt. Betrachtet man die Berechti-gungsobjekte, stößt man schon auf die erste Restriktion der Reportingberech-tigungen. Da sie denselben Aufbau wie Standard-Berechtigungsobjektehaben, ist die Anzahl der möglichen Felder auf zehn beschränkt.

Abbildung 8.1 Anlage eines Berechtigungsobjekts in der Transaktion RSSM

Es ist darüber hinaus möglich, die selbsterstellten Berechtigungsobjekte in dasProfil einer Rolle einzufügen und darin dem Benutzer die Ausprägungen dereinzelnen Merkmale zuzuordnen. Die Pflege der Berechtigungen liegt größ-tenteils innerhalb der Umgebung der SAP-Basis, der Rollenpflege. Es gibt inBW 3.x keine so komplette Infrastruktur, wie sie mit der Transaktion RSEC-ADMIN bereitgestellt wird, um zentral die Berechtigungen anzulegen undden Benutzern zuzuordnen. Die Pflege für Reportingberechtigungen findetmit Hilfe der Transaktion RSSM (Berechtigungen Business InformationWarehouse) statt. Dort werden die Berechtigungsobjekte auf Basis derberechtigungsrelevanten Merkmale angelegt. Merkmale können mehrmalsin unterschiedlichen Objekten verwendet werden. Ebenso können aus derTransaktion RSSM heraus Berechtigungen generiert werden, und Benutzernzugeordnet werden. Dafür wird je ein eigenes Profil mit den vergebenenWerten generiert, das dem Benutzer direkt ohne eine Rolle zugeordnet wird.Dabei kommt es jedoch immer wieder zu Problemen mit einer zentralenBenutzerverwaltung (ZBV) oder dem Identity Management. Von dieser Artder Berechtigungsgenerierung in BW 3.x ist also abzuraten, wenn das BW ineine ZBV integriert ist.

So wie es bei den Analyseberechtigungen der Fall ist, ist es auch bei Repor-tingberechtigungen möglich, mit Hierarchieberechtigungen und Variableninnerhalb der Berechtigungen zu arbeiten. Hierarchieberechtigungen wer-den in BW 3.x ebenfalls in der Transaktion RSSM erstellt und können auch


Migration8

480

dort für den Transport erfasst werden. Die Zuordnung von Berechtigungenauf Hierarchien erfolgt über das künstliche Merkmal 0TCTAUTHH (Berechti-gung auf Hierarchie). Dieses Merkmal muss in die selbsterstellten Berechti-gungsobjekte mit aufgenommen werden (siehe Abbildung 8.1): Angenom-men, die Kostenstelle und das Profit-Center sind berechtigungsrelevant,dann müssen »Kostenstelle«, »Profit-Center« und das Merkmal 0TCTAUTHHin ein Berechtigungsobjekt gepackt werden.

Hierbei ergeben sich weitere Nachteile. Aufgrund der verpflichtenden Nut-zung des Merkmals 0TCTAUTHH verliert man ein weiteres Feld im Objekt.Weit unangenehmer ist aber, dass man Berechtigungsobjekte nicht einfachso um ein Feld erweitern kann. Falls Merkmale anfangs keine Hierarchienhatten und diese erst im Laufe der Zeit angelegt wurden, enthalten dieBerechtigungsobjekte oftmals nicht das Merkmal 0TCTAUTHH. Somit musses nachträglich eingefügt werden. Da man Berechtigungsobjekte aber nichtändern kann, solange noch Berechtigungen dazu existieren, müssen alleBerechtigungen gelöscht und neu angelegt werden. Alternativ dazu kannman ein weiteres Berechtigungsobjekt mit denselben Merkmalen und demMerkmal 0TCTAUTHH einführen. Das Ergebnis ist, dass man nun zweiBerechtigungsobjekte anstelle von einem hat. Das wiederum erhöht dieKomplexität unnötig und schadet der Übersichtlichkeit.

Bei Analyseberechtigungen ist das kein Thema mehr. Hierarchieberechtigun-gen werden nun direkt innerhalb einer Analyseberechtigung angelegt. Dienachträgliche Änderung von Analyseberechtigungen ist ebenfalls problem-los möglich. Gerade auch deshalb, weil Analyseberechtigungen von der SAP-Basis abgekoppelt sind.

Der Vollständigkeit halber wollen wir das Objekt S_RS_AUTH erwähnen.Durch dieses sind Analyseberechtigungen nicht vollständig von Rollen losge-löst. Jedoch besteht inhaltlich nicht mehr eine so starke Abhängigkeit wiebei den Reportingberechtigungen, da nur die technischen Bezeichnungenvon Analyseberechtigungen und nicht die Werte selbst abgelegt werden.

Ein ganz entscheidender Unterschied zwischen Reporting- und Analysebe-rechtigungen ist, dass berechtigungsrelevante Merkmale bei Reportingbe-rechtigungen nicht systemweit geprüft wurden. In der Transaktion RSSMhatte man die Möglichkeit, die selbsterstellten Berechtigungsobjekte zur Prü-fung auf einem InfoProvider anzuschalten. Es war somit möglich, ein berech-tigungsrelevantes Merkmal nicht auf allen InfoProvidern, die es enthalten,zu prüfen.


Vergleich von altem und neuem Berechtigungskonzept 8.2

481

Bei den Analyseberechtigungen ist das nicht mehr möglich. Ist ein Merkmalberechtigungsrelevant, wird es nun in allen vorkommenden InfoProviderngeprüft. Dies ist ein strikter, aber im Gesamten logischer und klarer Ansatz.Jedoch ergeben sich daraus gerade für die Migration der BerechtigungenProbleme: Es muss vor dem Umschalten des Berechtigungskonzeptes sicher-gestellt sein, dass ein Benutzer, der auf dem InfoProvider B eine Query aus-führt, davor und danach dazu berechtigt ist. Abbildung 8.2 zeigt einen Aus-schnitt aus der Transaktion RSSM. Sie sehen die Prüfung für InfoProvider-Einstellungen des Berechtigungsobjekts ZCOSTCENTE. Hier wird sofort diezuvor angesprochene Problematik der nicht geprüften InfoProvider klar.

Abbildung 8.2 Anschalten von Berechtigungsobjekten zur Prüfung

Das Merkmal »Kostenstelle« kommt in den drei in der Abbildung aufgeführ-ten InfoProvidern vor, daher werden diese zur Auswahl angeboten. Jedochist die Prüfung nur für den ersten InfoCube angeschaltet. Bei den beidenanderen InfoCubes wird das Merkmal »Kostenstelle« nicht geprüft, obwohles berechtigungsrelevant ist. Dieses nicht konsistente Verhalten ist mit BW7.0 nicht mehr möglich, da alle berechtigungsrelevanten Merkmale in Info-Providern ausnahmslos geprüft werden.

In Tabelle 8.1 haben wir die zentralsten Unterschiede und Vorteile der Ana-lyseberechtigungen gegenüber den Reportingberechtigungen zusammenge-fasst.

Damit wollen wir den Vergleich zwischen altem und neuem Konzeptabschließen. Aus der vorangegangenen Tabelle werden die Vorteile der Ana-lyseberechtigungen eindeutig ersichtlich. Gehen Sie nun weiter, und überle-gen Sie, wie Sie die Migration der Berechtigungen vorbereiten können.

Keine systemweite Prüfung bei Reportingberechtigungen

Bei den Reportingberechtigungen in BW 3.x werden berechtigungsrelevanteMerkmale nicht systemweit geprüft.


Migration8

482

Reportingberechtigungen BW 3.x

Analyseberechtigungen abBW 7.0

Pflege Ein eigenes RSR-Klassen-Berechti-gungsobjekt zur Berechtigungs-anlage wird angelegt.

Berechtigungen werden direkt als Analyseberechtigungen erstellt.

Prüfung Berechtigungsobjekte müssen für die Prüfung auf einem InfoProvider zusätzlich angeschaltet werden.

Jedes berechtigungsrelevante Merkmal eines InfoProviders wird zur Prüfung herangezogen (Eindeutigkeit!).

Änderungen Berechtigungsobjekte sind nach-träglich nur änderbar, wenn dazu keine Berechtigungen existieren.

Analyseberechtigungen sind auch nachträglich einfach zu ändern.

Dimen-sionen

Begrenzung auf zehn Felder inner-halb eines Berechtigungsobjekts

Beliebige Anzahl von Merkma-len; als OLAP-Schranke gilt es, nicht mehr als zehn berechti-gungsrelevante Merkmale je Query zu verwenden.

Feldlängen Aufgrund der Länge eines Berech-tigungsfeldes ergibt sich eine Länge von zehn Zeichen. Daraus ergeben sich Mapping-Probleme für InfoObjects.

Bei Analyseberechtigungen ste-hen 30 Zeichen zur Verfügung. Somit ist auch die Abbildung von Navigationsattributen kein Problem.

Kompatibi-lität

Navigationsattribute können nicht je Merkmal berechtigt werden, und zusätzlich ist eine Berücksich-tigung der Kompatibilitätsmodi der Transaktion RSSM notwendig.

Navigationsattribute können an jedem InfoObject individuell als berechtigungsrelevant markiert werden.

Hierarchien Berechtigungen auf Hierarchien werden abseits der Merkmalswerte angelegt und gepflegt. Sie müssen über eine eindeutige ID, die nichts über den Inhalt der Berechtigung aussagt, in Profile eingepflegt wer-den (Intransparenz!).

Hierarchien werden direkt mit Merkmalswerten gepflegt und sind somit gleichwertig zu Werte- oder Intervallberechti-gungen.

Prüfmodus Jedes für die Abfrage relevante (zur Prüfung markierte) Berechtigungs-objekt muss einzeln in der Prüfung berechtigt sein.

Berechtigungen werden zusam-mengefasst, was dem erwarte-ten Verhalten der Benutzer ent-spricht.

Tabelle 8.1 Unterschiede zwischen 3.x- und 7.0-Berechtigungen


Vorbereitung und Analyse 8.3

483

8.3 Vorbereitung und Analyse

Um bei einer Migration erfolgreich zu sein, muss erst eine Bestandsauf-nahme der gegenwärtig implementierten Berechtigungsszenarien erfolgen.Ist eine solche Bestandsaufnahme bereits vorhanden, umso besser. Falls sienicht vorliegt, sollte sie zur Vorbereitung auf die Migration unbedingt durch-geführt werden.

Eine Migration wird testweise auf jeden Fall auch innerhalb der Transport-schiene durchgeführt und eventuell auf einem Sandbox-System getestet wer-den, bevor sie in der Entwicklungsumgebung umgesetzt wird.

Damit die Tests auch aussagekräftig und verlässlich sind, muss auf jeden Fallsichergestellt sein, dass Entwicklungs- und Produktivsystem nicht zu starkabweichen, gerade im Bezug auf Querys, Stammdaten und Hierarchien. Diesist eine weitere Vorbereitung für die Migration.

Ist es unter Umständen nicht möglich, die Migration auf der Entwicklungs-umgebung vorzubereiten, kann zur Sicherheit eine Systemkopie vom Pro-duktivsystem im Entwicklungssystem gemacht werden.

Wie sieht nun eine Bestandsaufnahme der bestehenden Reportingberechti-gungen für eine Migration im Detail aus?

Standard-berechti-gungen

Auch für die Ausführung einer Query werden Standardobjekte wie S_RS_HIER, S_RS_MPRO, S_RS_ISET usw. geprüft. Somit liegt keine klare Trennung der Berechtigungen im Modellie-rungs- und Reportingbereich vor.

Berechtigungen auf InfoProvi-der und Aktivitäten werden durch die dafür eingeführten und verpflichtend zu berechti-genden Spezialmerkmale 0TCAIPROV und 0TCAACTVT abgedeckt.

Gültigkeit Die Gültigkeit einer Berechtigung wird durch die Rollenpflege gesteuert.

Es kann eine beliebige, aber verpflichtende Gültigkeit über 0TCAVALID vergeben werden. Dabei sind Muster, bestimmte Zeiträume etc. erlaubt.

Reportingberechtigungen BW 3.x

Analyseberechtigungen abBW 7.0

Tabelle 8.1 Unterschiede zwischen 3.x- und 7.0-Berechtigungen (Forts.)


Migration8

484

8.3.1 Berechtigungsrelevante Merkmale

Zuerst sollte man sich einen Überblick über alle berechtigungsrelevantenMerkmale im System verschaffen. In der Transaktion RSSM ist dies recht ein-fach möglich. Wie in Abbildung 8.1 zu sehen ist, erhält man in der Detailan-sicht zu den Berechtigungsobjekten eine Liste aller berechtigungsrelevantenMerkmale, die im System vorkommen.

Warum ist dieser Überblick über die berechtigungsrelevanten Merkmale sowichtig? In den Releases BW 3.x war die Markierung eines Merkmals alsberechtigungsrelevant mit keiner tatsächlichen Prüfung verbunden. Dasführte in der Vergangenheit teilweise dazu, dass Merkmale »sicherheitshal-ber« als berechtigungsrelevant markiert wurden. Wenn der Schalter auf Ana-lyseberechtigungen umgelegt wird, werden alle in der Transaktion RSSMgezeigten Merkmale geprüft. Das bedeutet, es kommt auch bei den »sicher-heitshalber« als berechtigungsrelevant markierten Merkmalen zu einer Prü-fung. Diese wird häufig nicht erfolgreich durchgeführt werden können.

Genau diese Art von Merkmalen, die als berechtigungsrelevant gekennzeich-net sind, aber nicht als solche genutzt werden, kann am Beginn der Migrationabgefangen werden. Wenn klar ist, dass diese Merkmale gegenwärtig nichtgenutzt werden, ist es ein Leichtes, sie auf nicht berechtigungsrelevant zu set-zen. Damit ändert sich am aktuellen Verhalten der Berechtigungsprüfungabsolut nichts. Die Merkmale wurden zuvor ja auch nicht berücksichtigt.

Was sich durch diese Überprüfung ändert, sind der zeitliche Aufwand unddie Komplexität der Migration. Der gesamte Prozess der Migration wirddadurch massiv vereinfacht. Die Merkmale können bei Bedarf jederzeit wie-der auf berechtigungsrelevant gesetzt werden, wenn zukünftig die Anforde-rung bestehen sollte, sie für ein neu zu implementierendes Berechtigungs-szenario zu verwenden.

Nicht genutzte berechtigungsrelevante Merkmale

Indem Sie sich einen Überblick über die berechtigungsrelevanten Merkmale ver-schaffen, die fälschlich so kategorisierten Merkmale erkennen und noch vor derMigration auf nicht berechtigungsrelevant setzen, können der Migrationsaufwandund zukünftige Probleme der Analyseberechtigungen bei Nichtbeachtung dieserMerkmale entscheidend minimiert werden.


Vorbereitung und Analyse 8.3

485

8.3.2 Liste der RSR-Berechtigungsobjekte

Weiterhin benötigt man unbedingt eine Liste der RSR-Berechtigungsobjekte,die im System angelegt wurden. Diese Liste kann aus der Transaktion RSSModer der Transaktion SU21 abgezogen werden. In Abbildung 8.3 sehen Siedas Berechtigungsobjekt ZXVTPROD und dessen Felder aus der TransaktionSU21. Die Felder sind mit den beiden Merkmalen XVTCPROD und0TCTAUTHH gefüllt.

Die erste Stelle für XVTCPROD ist eine »9«. Wenn es sich um ein Merkmal ineinem RSR-Berechtigungsobjekt handelt, dann wird an die erste Stelle eine»9« gesetzt 1. Handelt es sich um ein SAP-Content-Objekt, dann wird wiebei 0TCTAUTHH die führende »0« abgeschnitten 2.

Abbildung 8.3 Transaktion SU21 – Detailansicht eines RSR- Berechtigungsobjekts

Sie sollten sich dadurch nicht verwirren lassen, dieser Sachverhalt ist nur fürden Abgleich der Berechtigungsobjekte mit den berechtigungsrelevantenMerkmalen wichtig. Dies ist auch gleich der nächste Punkt, dem wir unswidmen, wenn die beiden Listen vorliegen: Es muss nun ein Abgleich statt-finden, damit man die im System berechtigungsrelevanten, aber nicht für diePrüfung verwendeten Merkmale identifizieren kann.

Das ist nun genau jene Gruppe von Merkmalen, die Sie – wie zuvor ange-merkt – auf nicht berechtigungsrelevant setzen können. Die SAP-Spezial-merkmale wie 0TCT* oder 0TCA* sind davon natürlich ausgenommen. DerRest wird jedoch im Rahmen des SAP-Standards der Berechtigungsprüfungnicht benötigt. Damit fallen einige Merkmale weg, die bei der Migrationnicht beachtet werden müssen. Der Gesamtaufwand verringert sich dadurchenorm.


Migration8

486

8.3.3 Das Prüfungsverhalten im System

Sind nun die für die Migration nicht relevanten Merkmale eliminiert, kom-men wir zum Prüfverhalten im System. Dieser Punkt ist besonders entschei-dend für das Gelingen der Migration. Sie sollten das aktuelle Prüfverhaltendes Systems vor der Migration kennen. Was verstehen wir darunter? In derTransaktion RSSM erhalten Sie für ein Berechtigungsobjekt eine Liste mitInfoProvidern, die für dieses zur Prüfung angestellt werden können. DasPrüfverhalten im System ist die komplette Auflistung der möglichen Kombi-nationen von Berechtigungsobjekten, InfoProvidern und des aktuellen Sta-tus der Prüfung für solch eine Kombination.

Um den aktuellen Stand des Prüfverhaltens in Erfahrung zu bringen, müssenSie den in Abbildung 8.4 gezeigten Button Prüfstatus (Berechtigungs-objekte, InfoProvider) aktualisieren in der Transaktion RSSM anklicken.Damit wird überprüft, welche Berechtigungsobjekte für welche InfoProvideraktiviert werden können und welche Zuordnungen bereits aktiviert sind.Anschließend erfolgt eine Aktualisierung der zugrunde liegenden Tabellen,in denen diese Information hinterlegt ist.

Abbildung 8.4 Aktualisierung des Prüfstatus

In der Transaktion RSSM muss man nun die InfoProvider ausfindig machen,für die ein Berechtigungsobjekt geprüft werden kann. Dazu muss ein Berech-tigungsobjekt in das vorgesehene Feld eingetragen und danach der PunktPrüfung für InfoProvider markiert werden. Ein Klick auf den ButtonAnzeigen gibt eine Liste wie in Abbildung 8.2 aus. Diese Darstellung derBerechtigungsobjekte und potenziell zu prüfender InfoProvider schränktnicht ein, ob ein InfoProvider für das Reporting relevant ist oder nicht. Eswerden einfach alle InfoProvider aufgelistet, die ein oder mehrere berechti-gungsrelevante Merkmale enthalten, sowie die dazu passenden Berechti-gungsobjekte. Somit werden in der Liste zu viele Datenziele angezeigt. Basis-Cubes oder DSOs aus dem Data-Staging-Bereich interessieren uns nicht, weilsie für das Reporting und somit auch für das Berechtigungskonzept nicht rele-vant sind. Sie können bedenkenlos aus der Liste entfernt werden.

Aufpassen muss man aber bei den InfoProvidern, die für das Reportinggenutzt werden, bei denen aber keine Prüfung aktiv ist. Genau diese sind fürdie Migration sehr spannend, denn bei den Analyseberechtigungen werden


Aufbau des Migrationskonzeptes 8.4

487

auch sie geprüft. Bis jetzt sind diese InfoProvider aber nicht mit Berechti-gungen versehen. Hier muss auf jeden Fall nachgearbeitet werden, da eineautomatische Migration keine Berechtigungen für diese InfoProvider anle-gen kann.

Nach diesen Schritten haben Sie einen guten Überblick über den Systemzu-stand bezüglich Berechtigungen. Sie wissen, welche Merkmale berücksich-tigt werden müssen, welche vernachlässigt werden können und welche RSR-Berechtigungsobjekte aktiv sind und migriert werden müssen. Letztendlichwissen Sie auch, wo Problemfelder liegen, für die man auf jeden Fall einespezielle/manuelle Lösung entwerfen muss.

8.3.4 Identifizieren der kritischen Reportinganwendungen

Im Rahmen der Überprüfung der bestehenden Berechtigungen sollte manauch die »kritischen« Reportinganwendungen herausfiltern. Unter kritischenAnwendungen versteht man solche, die intensiv von einer großen Benutzer-anzahl genutzt werden und auf jeden Fall für das Reporting zur Verfügungstehen müssen. Diese kritischen Anwendungen sollten besonders sorgfältigbei der Migration behandelt werden.

8.4 Aufbau des Migrationskonzeptes

Um das Berechtigungskonzept zu wechseln, brauchen Sie einen genauenPlan, da sonst Berechtigungsprobleme beim Umstellen vorprogrammiertsind. Mit den bereits besprochenen Vorarbeiten hat man eine gute Basis, umdiesen Plan zu erstellen. Wenn wir von Migration sprechen, denken Sie ver-mutlich in erster Linie an Aufwände und mögliche Probleme, die bei derUmstellung entstehen können. Aber Sie sollten auch bedenken, dass hier einevielleicht einmalige Chance entsteht, die Berechtigungen zu überarbeiten.

Wann hat man schon die Möglichkeit, alle Berechtigungsimplementierungenzu überdenken und unter Umständen Teile davon neu aufzubauen? Da dieModelle bereits im Einsatz sind, weiß man, ob sie praktikabel und unkom-pliziert zu warten sind bzw. was optimiert werden kann. Gibt es keine Pro-bleme, werden die Berechtigungen auf die neuen Analyseberechtigungenumgestellt. Falls es Verbesserungspotential gibt, können Sie sich ausgehendvon den bekannten Problemfällen Gedanken machen, wie die Modelle ver-bessert werden können.


663

Index

$$$_ � Benutzergruppe* � Gesamtberechtigung* � Muster+ � Muster0BI_ALL 115, 141, 163, 251, 287, 301,

6050HIER_NODE 147, 284, 5400TCA_DS01 1670TCA_HIE 2960TCA_UA 2960TCA_VAL 2960TCAACTVT 40, 50, 136, 267, 6010TCAIFAREA 1510TCAIPROV 40, 50, 125, 133, 151, 267,

287, 517, 6010TCAKYFNM 91, 102, 127, 128, 137,

5150TCAVALID 40, 50, 125, 134, 267, 288,

525, 532, 6010TCTADFROM 1690TCTAUTHH 5050TCTIOBJNM 1700TCTOPTION 1690TCTSIGN 1690TCTUSERNM 1671HIER_REST 147, 5401NODENAME 540

A

Ablauf-Optimierung 589ACTVT 517Adobe Document Service 240Aggregation 59Aggregationsberechtigung 35, 41, 59,

122, 123, 263, 273, 533, 610Aggregationsebene 591

Anlegen 651, 653Merkmalsselektion 653

AktivitätAusführen (16) 591Standardberechtigungsobjekt 207

Aktivitätsberechtigung 230

Analyseberechtigung 110, 120, 368aufgefüllte 462Benutzern zuordnen 395bestehende Modelle 345Daten-Schreibberechtigung 344Definieren 398direkte Benutzerzuordnung 323Fragenkatalog im Projekt 315für zwei Merkmale 463generierungsbasierte 434Hierarchie für 0TCTAUTH 341InfoProvider-basierte 334Integrierte Planung 343Leitsätze 54Mischen 461, 464operatives Modell 346Transport 110USER_PCT 437USER_WERK 438variablenbasierte 393Vorgenerieren 355XVT_BI_ALL 376zukünftige Entwicklung 316Zuordnung 320

Analyseberechtigungsmodellgenerische Modelle 332InfoObject-basiertes 335InfoProvider-basiertes 333Merkmale zusammenfassen 339Mischformen 336, 343Vor- und Nachteile 337, 343

Analyseprozess-Designer 224Analytics Security Objects 153analytischer Index 224Änderungsart 298Änderungsbeleg 294Anleitung Demo-Content 645Anwendungskomponente anlegen 646Anzeigeattribut 100, 102, 127Anzeigehierarchie � HierarchieAPD � Analyseprozess-DesignerArbeitsmappe

Anlegen 381Ausführen 418Erstellen 376


664

Index

Archivierung � Transaction SARAAudit 296Aufriss 51Ausdünnung � HierarchieberechtigungAusführen als... 252Ausführen als... � Transaktion RSUDOAusführungsberechtigung �

S_RS_COMPAusschlussmenge � ExcludingAuthentifizierung 617automatische Filterung 541

B

Backend-System 617BAdI 593Barriere 612Barriereprinzip 53Basisberechtigungsobjekt 366BasisCube 370, 372

Anlegen 371Übernehmen 651

bebuchbarer Knoten 284Benutzer 111

Anlegen 398D_E_L_E_T_E 354eingeschränkt berechtigter 49viele vereinzelte Berechtigungen 461

Benutzeraktualisierung 620Benutzerberechtigung 401, 474Benutzergruppe 308, 611, 622Benutzerpflege � Transaktion SU01Benutzersicherheit 625, 626Benutzertyp 202, 325Benutzerzuordnung 44, 111, 157, 167,

4400TCA_DS05 167direkte 324

BerechtigungAggregationsberechtigung 35, 59Analyse in ERP 212Anlegen 39Attribut zum Merkmal 103BAdI 593Barriereprinzip 53Customer-Exit 593Filterprinzip 53in der Planung testen 450

Berechtigung (Forts.)Kombinieren 577, 579manuelle oder generierte 44mehrdimensionale 73, 174, 403, 407Merkmal eines InfoProviders 42Mischen 577, 580mit SID 573Namensvergabe 168objektorientiert 624OLAP 24OLTP 24Optimieren 577Power-User 237Prüfen 42, 397Pufferung 577Typ der Hierarchieberechtigung 65Variable 54, 592Vereinfachen 580verweigern 624viele vereinzelte 459virtuelle 593zeitintensiv Mischen 463Zuordnung 44

Berechtigung und Exit-Variable 414Berechtigungen zusammenfassen 288Berechtigungen, sortierte 465Berechtigungsdefinition 400Berechtigungsfeld 219, 220

Dokumentation 206zulässige Aktivität 206

Berechtigungsgruppe 611Berechtigungskombination 398

mehrdimensionale 340Berechtigungskonzept

Definition 303ohne Analyseberechtigung 312

Berechtigungskonzept BW 202Berechtigungsmeldung

EYE 007 46, 266, 570EYE 018 265EYE 019 547keine ausreichende Berechtigung 570

BerechtigungsmodellAblauf 306Anforderung 309Anforderungsprofil 303Beginn 308Benutzergruppe 308Benutzertyp 325


665

Index

Berechtigungsmodell (Forts.)berechtigungsrelevantes Merkmal 309,

315bestehende Standardberechtigung 331bestehendes 305BW-Projekt 304Datenberechtigung 309Definition 303Entscheidungsbaum 309Grundmodell der Standard-

berechtigungen 315, 325InfoProvider-basiertes 333, 335Lösungsansätze 303Menürolle 328Modelldefinition 305Modellentscheidung 311Namensraum 312Rollenmodell 328Standardrollenkonzept 308Testen 390Vorlage 326

BerechtigungsobjektBasis 366BEx Web Application Designer 240BW Query 228Datenfluss 222ERP und BW 209S_ADMI_FCD 366S_CTS_ADMI 213, 366S_DATASET 366S_DEVELOP 212, 366S_GUI 212, 366, 386S_RFC 228, 234, 366, 386, 618S_RO_BCTRA 213, 214S_RO_OSOA 214S_RS_ADMWB 216, 225, 368S_RS_AINX 222, 224S_RS_ALVL 238S_RS_AUTH 228, 233, 321, 322, 386S_RS_BCS 240S_RS_BEXTX 240, 242S_RS_BITM 240S_RS_BTMP 241S_RS_COMP 205, 207, 228, 231, 385,

618S_RS_COMP1 228, 230, 231, 385S_RS_CPRO 222, 225S_RS_DMOD 222S_RS_DTP 220

Berechtigungsobjekt (Forts.)S_RS_FOLD 228, 232, 233S_RS_HIER 226S_RS_HYBR 222, 224S_RS_ICUBE 222, 225S_RS_IOBC 225S_RS_IOBJ 225S_RS_IOMAD 226S_RS_ISET 225S_RS_ISRCM 219S_RS_LPOA 222, 224S_RS_MPRO 222S_RS_ODSO 222, 368S_RS_PC 221S_RS_PLENQ 238, 239S_RS_PLSE 238, 239S_RS_PLSQ 238, 239S_RS_PLST 238, 239S_RS_RSTT 228, 233, 368S_RS_TR 219, 220S_RS_XCLS 242S_RSEC 112, 367S_TABU_CLI 366S_TABU_DIS 212, 213, 366S_TABU_LIN 213, 226S_TCODE 211, 214, 366S_USER_AGR 228, 367, 385, 388S_USER_GRP 367S_USER_PRO 367S_USER_TCD 237, 367, 385, 388S_USER_VAL 367

Berechtigungspflege � Transaktion RSECAUTH

Berechtigungsprotokoll 256, 396, 402Aggregationsberechtigung 271Aggregationsberechtigungsprüfung 270Archivierung 292Attribut 261bei unterschiedlichen Hierarchien 425Berechtigungen zusammenfassen 288detaillierte Berechtigungsprüfung 270Exit-Variable 284, 413Hauptprüfung 270Hierarchieknoten-Berechtigung 264Hierarchieprüfung ohne Berechtigung

421InfoProvider-Prüfung 267Kunden-Exit 285Optimierungen 285


666

Index

Berechtigungsprotokoll (Forts.)Protokollaufbau 258Protokollaufzeichnung 258Protokollkopf 260Protokollverwaltung 256Prüfungsbestandteile 266Pufferung 286relevante InfoObjects 268SQL 278verwendete Objekte 282Vorverarbeitung 270Werte- und Knotenprüfung 275Wertehilfen und Variablen 261Wertevariablen 262

Berechtigungsprotokoll (kla

Documents

Berechtigungen in SAP NetWeaver BW - ReadingSample · In SAP NetWeaver BW gibt es unterschiedliche Arten von Berechtigungen. Sie haben gemeinsam, dass sie – sinnvoll implementiert