SAP PRESS Berechtigungen in SAP NetWeaver BW Bearbeitet von Peter John, Peter Kiener erweitert 2012. Buch. ca. 676 S. Hardcover ISBN 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 Programm durch Services wie Neuerscheinungsdienst oder Zusammenstellungen von Büchern zu Sonderpreisen. Der Shop führt mehr als 8 Millionen Produkte.
Transcript
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
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
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.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
1870.book Seite 8 Freitag, 4. Mai 2012 9:35 09
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
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
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
5.2 Grundmodelle der Standardberechtigungen ........................... 3255.2.1 Einteilung der Benutzertypen .................................... 325
1870.book Seite 9 Freitag, 4. Mai 2012 9:35 09
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
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
1870.book Seite 10 Freitag, 4. Mai 2012 9:35 09
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
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.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
1870.book Seite 11 Freitag, 4. Mai 2012 9:35 09
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
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.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
A FAQ ................................................................................................. 635B Wichtige DataStore-Objekte für die Generierung ............................. 639C Anleitung – Implementierung der Beispiele aus Kapitel 6 ................. 645D Die Autoren ..................................................................................... 661
Index ...................................................................................................... 663
1870.book Seite 13 Freitag, 4. Mai 2012 9:35 09
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-
1870.book Seite 17 Freitag, 4. Mai 2012 9:35 09
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.
1870.book Seite 18 Freitag, 4. Mai 2012 9:35 09
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.
1870.book Seite 19 Freitag, 4. Mai 2012 9:35 09
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
1870.book Seite 20 Freitag, 4. Mai 2012 9:35 09
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
1870.book Seite 21 Freitag, 4. Mai 2012 9:35 09
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.
1870.book Seite 303 Freitag, 4. Mai 2012 9:35 09
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.
1870.book Seite 304 Freitag, 4. Mai 2012 9:35 09
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.
1870.book Seite 305 Freitag, 4. Mai 2012 9:35 09
Anforderungsprofile und Lösungsansätze5
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
1870.book Seite 306 Freitag, 4. Mai 2012 9:35 09
Das Berechtigungsmodell im BW-Projekt 5.1
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.
1870.book Seite 307 Freitag, 4. Mai 2012 9:35 09
Anforderungsprofile und Lösungsansätze5
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.
1870.book Seite 308 Freitag, 4. Mai 2012 9:35 09
Das Berechtigungsmodell im BW-Projekt 5.1
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.
1870.book Seite 309 Freitag, 4. Mai 2012 9:35 09
Anforderungsprofile und Lösungsansätze5
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
1870.book Seite 310 Freitag, 4. Mai 2012 9:35 09
Das Berechtigungsmodell im BW-Projekt 5.1
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-
1870.book Seite 311 Freitag, 4. Mai 2012 9:35 09
Anforderungsprofile und Lösungsansätze5
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
1870.book Seite 312 Freitag, 4. Mai 2012 9:35 09
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.
1870.book Seite 477 Freitag, 4. Mai 2012 9:35 09
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-
1870.book Seite 478 Freitag, 4. Mai 2012 9:35 09
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 Information
Warehouse) 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
1870.book Seite 479 Freitag, 4. Mai 2012 9:35 09
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.
1870.book Seite 480 Freitag, 4. Mai 2012 9:35 09
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.
1870.book Seite 481 Freitag, 4. Mai 2012 9:35 09
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
1870.book Seite 482 Freitag, 4. Mai 2012 9:35 09
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.)
1870.book Seite 483 Freitag, 4. Mai 2012 9:35 09
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.
1870.book Seite 484 Freitag, 4. Mai 2012 9:35 09
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.
1870.book Seite 485 Freitag, 4. Mai 2012 9:35 09
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
1870.book Seite 486 Freitag, 4. Mai 2012 9:35 09
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.
