sap – der technische einstieg · ein programm abgefragt werden kann. ddic der standardbenutzer...

67

3

Kapitel 3

Mandanten

In diesem Kapitel ...

... lernen Sie:

� was Mandanten sind

� welche Standardmandanten es gibt

� welche SAP-Standardbenutzer verfügbar sind

� wie Sie Mandantenrollen nutzen und verwalten

Mandanten sind in einem SAP-System die obersten Ordnungskriterien zur

Steuerung und Verwaltung von Geschäftsprozessen oder Entwicklungsar-

beiten. Über die Festlegung von Mandanten kann hierüber eine klare Tren-

nung herbeigeführt werden. Darüber hinaus gibt es Standardmandanten,

die SAP für sich selbst nutzt und die als Referenz zur Einrichtung eigener

Mandanten genutzt werden können.

RepositoryEin SAP-System arbeitet immer nur mit einer Datenbank zusammen und

hat demzufolge auch nur ein Repository (siehe Abschnitt 1.3, »Die Rolle der

Datenbank« ). Darin wird die Laufzeitumgebung erzeugt, und darin werden

die Kundendaten angelegt und gepflegt. Kundendaten sind sensible Daten,

auf die nicht jeder Zugriff haben soll. So sollen z. B. Mitarbeiter des Zah-

lungsverkehrs einer Bank nicht Zugriff auf das Wertpapiersystem dieser

Bank haben. Mitarbeitern des Controllings wiederum soll es nicht gestattet

sein, Einsicht in die Einlagen von Bankkunden zu erhalten. Auf der Ebene

des Qualitätstests ist eine saubere semantische Trennung der Testdaten

gewünscht. Damit sich die Daten unterschiedlicher fachlicher Systeme

nicht vermischen und der Zugang zu diesen Daten gesteuert werden kann,

gibt es unter SAP den Mandanten (englisch: client).

MandantenMit Mandanten soll auch eine Mischung zwischen Produktion, Test und

Entwicklung verhindert werden, indem den einzelnen Mandanten spezifi-

sche Rollen zugewiesen werden. Der Mandant stellt den obersten Ord-

nungsbegriff in einem SAP-System dar. Der Zugriff auf einen Mandanten

kann über das Berechtigungswesen gesteuert werden.

3 Mandanten

68

Mandant SAP definiert den Mandanten als eine »für sich handelsrechtlich, organisato-

risch und datentechnisch abgeschlossene Einheit« (http://s-prs.de/v433209).

Ein Mandant ist technisch gesehen nichts weiter als eine dreistellige Ziffer,

die an erster Stelle eines Schlüsselbegriffs in einer Datenbanktabelle steht.

Das heißt, der Mandant ist in einer Datenbanktabelle immer das erste

Datenfeld. Als Konvention wird dieses Feld MANDT genannt und ist vom

Datentyp CLNT. Dadurch, dass der Mandant an erster Stelle steht, steht er

auch in der Schlüsselhierarchie an erster Stelle, wodurch eine saubere Tren-

nung der Daten nach Mandanten möglich ist. Eine Datenbank kann bis zu

1.000 Mandanten, von 000 bis 999, aufnehmen.

Schlüsselhierarchie Über eine Schlüsselhierarchie wird die Sortierreihenfolge eines zusammen-

gesetzten Schlüssels bestimmt. Der Mandant wird niemals ein alleiniger

Schlüssel einer Datenbanktabelle sein. Vielmehr wird es einen zweiten oder

dritten Schlüssel für jede Tabelle geben, die den eindeutigen semantischen

Inhalt dieser Tabelle widerspiegeln. Somit haben Sie es immer mit einem

zusammengesetzten Schlüssel zu tun, wenn die Daten dieser Tabelle man-

dantenabhängig sind. Eine Ausnahme ist die Tabelle T000. In dieser Sys-

temtabelle werden die Mandanten eines SAP-Systems festgehalten. Hier ist

lediglich der Mandant der Schlüssel.

Die Sortierreihenfolge wird über die Position der als Schlüssel deklarierten

Felder innerhalb der Tabelle bestimmt. Die oberste Position wird zuerst

sortiert, dann, innerhalb dieser Reihenfolge, die nächstfolgende Position

usw. Abbildung 3.1 zeigt ein Beispiel.

Abbildung 3.1 Beispiel einer Customizingtabelle mit dem Mandanten an Position 1

Datentyp CLNT Der Datentyp CLNT dient im SAP Dictionary ausschließlich der Typisierung

des Mandanten. Den Aufbau von Tabellen und den einzelnen Dictionary-

Elementen beschreiben wir in Kapitel 5, »ABAP-Dictionary-Objekte«.

Wenn ein Benutzer sich an einem SAP-System anmeldet, muss er zualler-

erst den Mandanten angeben, unter dem er arbeiten möchte. Das SAP-Sys-

3.1 SAP-Standardmandanten

69

3

tem merkt sich für diesen Benutzer den Mandanten und sorgt dafür, dass

der Benutzer nur auf Daten dieses Mandanten zugreifen kann und nicht

auf Daten anderer implementierter Mandanten. In Datenbanktabellen mit

mandantenabhängigen Daten können die Daten mehrerer Mandanten ge-

speichert sein.

3.1 SAP-Standardmandanten

Bei der Installation eines SAP-Systems werden automatisch drei Mandan-

ten angelegt:

� Mandant 000

� Mandant 001

� Mandant 066

3.1.1 Mandant 000

Der Mandant 000 dient als Referenzmandant. Er darf nicht verändert oder

produktiv verwendet werden. Dieser Mandant enthält die folgenden Ein-

stellungen:

� voreingestellte Systemtabellen

� Beispiele für Organisationseinheiten

� Standardcustomizing-Einstellungen als Referenz

Buchungskreis 0001Über den Buchungskreis 0001 des Mandanten 000 wird das von SAP ausge-

lieferte Standardcustomizing abgebildet. Ein Buchungskreis ist innerhalb

eines SAP-Systems die kleinste organisatorische Einheit, für die eine Bilan-

zierung erstellt werden kann. Beim Einrichten eines neuen Mandanten

können von diesem Mandanten Einstellungen übernommen werden.

System-Upgrades

und Releasewechsel

System-Upgrades und Releasewechsel finden über den Mandanten 000

statt und werden von dort aus an andere Mandanten über das Release-

Customizing weiter geleitet. Folgende Inhalte werden dabei aktualisiert:

� Tabellenstrukturen und -inhalte

� Programme

� Bildschirmbilder

� Formulare

� Onlinehilfe

� SAP-Referenz-Einführungsleitfaden

3 Mandanten

70

Der Einführungsleitfaden (englisch: IMG = Implementation Guide) wird mit

Transaktion SPRO aufgerufen und ist Einstiegspunkt für das Customizing.

3.1.2 Mandant 001

Der Mandant 001 ist eine Kopie des Mandanten 000 und dient als Produkti-

onsvorbereitungsmandant. Er ist für das kundenspezifische Customizing

vorgesehen. Im Produktivbetrieb selbst darf mit diesem Mandanten eben-

falls nicht gearbeitet werden. Eine Ausnahme stellen jedoch der SAP Solution

Manager und SAP Business Warehouse dar, die unter diesem Mandanten pro-

duktiv betrieben werden können. Zusätzlich kann hier mit Hilfe des Custo-

mizings über den Mandanten 001 eine Testumgebung aufgebaut werden.

Bei einem System-Upgrade oder Releasewechsel im Mandanten 000 müs-

sen diese Änderungen in diesem Mandanten nachgezogen werden.

3.1.3 Mandant 066

Der Mandant 066 wurde bis zur SAP-NetWeaver-Version 7.50 als Referenz-

mandant für das sogenannte EarlyWatch mit ausgeliefert. Allerdings wird

dieser Mandant hierfür von SAP nicht mehr verwendet (vergleiche SAP-

Hinweis 1749142) und kann bei Bedarf gelöscht werden.

EarlyWatch EarlyWatch bezeichnet die Überwachung der Performance eines SAP-

Systems gemeint. Dieses Monitoringverfahren ist Teil des CCMS (SAP Com-

puting Center Management System). Darüber werden u. a. die Leistungen

von Server, Datenbank, Anwendungen, Konfigurationen und die System-

belastung gemessen. Die Ergebnisse dieser Messungen werden in einem

Statusbericht festgehalten und enthalten auch Empfehlungen zu Tuning-

maßnahmen. Eine gute Beschreibung von EarlyWatch befindet sich in dem

Buch Sebastian Schreckenbach, SAP-Administration, SAP PRESS Bonn, 2015,

S. 230 ff.

3.1.4 SAP-Standardbenutzer

Standardbenutzer Bei der Installation von SAP NetWeaver AS ABAP werden Standardbenutzer

angelegt, die teilweise nur in den aufgeführten Standardmandanten vor-

handen sind und denen bestimmte Aufgaben zugedacht wurden. Es gibt

die folgenden Standardbenutzer:

� SAP*

SAP* ist der System-Super-User von SAP NetWeaver AS und ist bei den

Mandanten 000, 001 und allen weiteren neuen Mandanten vorhanden.

3.2 Mandantenrollen und Systemlandschaften

71

3

Dieser Standardbenutzer darf nicht gelöscht werden. Er liegt hartcodiert

vor, und es ist für ihn kein Benutzerstammsatz notwendig. Hartcodiert

bedeutet, dass etwas Teil eines Programmcodings ist. Das Gegenteil zu

hartcodiert ist etwa die Auslagerung in eine Datenbanktabelle, die über

ein Programm abgefragt werden kann.

� DDIC

Der Standardbenutzer DDIC verfügt über Sonderrechte bei der System-

installation und bei System-Upgrades sowie für das ABAP Dictionary.

Der Benutzerstammsatz für den Benutzer DDIC wird bei der Installation

des SAP-Systems in den Mandanten 000 und 001 automatisch angelegt.

Der Benutzer sollte nicht gelöscht werden.

� EARLYWATCH

Der Benutzer EARLYWATCH ist der Dialogbenutzer für EarlyWatch im

Mandanten 066.

� SAPCPIC

Über den Standardbenutzer SAPCPIC können RFC-Verbindungen (Re-

mote Function Call) zu anderen SAP-Systemen aufgebaut werden. Dieser

Benutzer wird mit der Installation eines SAP-Systems angelegt und ist in

den Mandanten 000, 001 und allen weiteren neuen Mandanten vorhan-

den. Falls der Benutzer SAPCPIC nicht benötigt wird, kann er gelöscht

werden.

� TMSADM

Der Standardbenutzer TMSADM wird für das Change-und-Transport-

System verwendet. Er wird bei der Konfiguration des Transport Manage-

ment Systems (TMS) automatisch generiert und befindet sich im Man-

danten 000. Die Kommunikation zwischen SAP-Systemen geschieht

über RFC-Verbindungen, und zwar einmal als Lese- und einmal als

Schreibzugriff. Von außerhalb eines SAP-Systems sind ohne Berechti-

gung keine Zugriffe auf das TMS innerhalb eines SAP-Systems möglich.

Die Berechtigungsprüfung geschieht im Zielsystem eines Transports.

Der Benutzer TMSADM ist der einzige Benutzer, dem beim Anlegen diese

Rechte automatisch zugeteilt werden.


RollenEine Systemlandschaft, wie sie von SAP empfohlen wird, haben wir Ihnen

in Abschnitt 1.4 vorgestellt. Die Zuteilung einer Rolle für einen Mandanten

ist eng gekoppelt mit einer festgelegten SAP-Systemlandschaft in einem

Unternehmen. Die Rolle eines Mandanten ist abhängig von den Aktivitä-

3 Mandanten

72

ten, die in einem SAP-System erlaubt sind. So sollten in einem Produk-

tivsystem keine Entwicklungsarbeiten gestattet sein. Über die Zuteilung

einer Mandantenrolle wird bestimmt, was in einem Mandanten grundsätz-

lich erlaubt ist und was nicht. In Tabelle 3.1 sind die möglichen Rollen aufge-

führt, die einem Mandanten zugeordnet werden können.

Im Einzelnen bedeuten die Rollen Folgendes:

� Produktiv

Über diese Rolle wird sichergestellt, dass der Mandant nicht gelöscht

werden kann. Bei einer Mandantenkopie können keine mandanten-

unabhängigen Änderungen vorgenommen werden. Dadurch sollen In-

konsistenzen im System verhindert werden. Mandanten in einem

Produktivsystem haben üblicherweise diese Rolle.

� Qualitätstest

Diese Rolle ist zum Testen von Funktionalität und Customizing vor Pro-

duktionseinführung vorgesehen. Der Test sollte zusammen mit einem

Fachbereich durchgeführt werden. Liefern die Programme und das

Customizing das, was fachlich erwartet wird? Da der Test gegebenenfalls

mit einem Produktionsvollbestand erfolgt, wird auf dieser Ebene gleich-

zeitig ein Lasttest durchgeführt. Wie ist das Performanceverhalten unter

Echtbedingungen? Von hier aus erfolgt die Freigabe für die Überführung

in das produktive System. In einem Qualitätssicherungssystem sollte

diese Rolle vergeben werden.

� Customizing

Mandanten mit dieser Rolle sind für die Pflege von Customizing (sowohl

mandantenabhängiges als auch -unabhängiges) und Entwicklung von

Funktionalität (z. B. Programmen) bestimmt. Customizing und Pro-

Rolle Abkürzung

Produktiv PROD

Qualitätstest QTEST

Customizing CUST

Schulung TRNG

Demo DEMO

Sandkasten SAND

Tabelle 3.1 Mögliche Rollen eines Mandanten


73

3

grammentwicklung können nur in Mandanten mit dieser Rollenspezifi-

kation vorgenommen werden. Von hier aus werden Entwicklungen

weiter in das Qualitätssicherungssystem und nach erfolgreichem Test

schließlich in das produktive System transportiert. Diese Rolle wird

Mandanten in einem Entwicklungs- und Wartungssystem zugeordnet.

� Schulung

Dient dazu, Schulungen in einem eigenen Mandanten durchzuführen.

Auch hier sollte keinerlei Verbindung zu einem produktiven System

bestehen.

� Demo

Hier können Sie Demonstrationen in einem gesonderten Mandanten

durchführen. Mandanten mit dieser Rolle sollten keinerlei Verbindung

zum produktiven System haben.

� Sandkasten (Sandbox)

Das ist die Spielwiese für Entwickler. Hier können Sie z. B. Programm-

codes, aber auch Customizingeinstellungen ausprobieren.

Mandantenkopierer

Über eine Mandantenkopie werden von einem Quellmandanten alle Ein-

stellungen und Daten oder Teile davon in einen Zielmandanten kopiert.

Dies wird beispielsweise häufig bei der Neuanlage eines Testmandanten

im Qualitätssicherungssystem gemacht, wobei produktive Anwenderda-

ten für die Tests mit dem Fachbereich bis zu einem bestimmten Stichtag

übernommen werden.

Zunächst muss der neue Mandant über Transaktion SCC4 angelegt wer-

den. In dem neuen Mandanten wird der Standardbenutzter SAP* mit dem

Passwort »PASS« generiert. Dieser Benutzer verfügt über alle Rechte, die

für eine Mandantenkopie benötigt werden. Allerdings ist dieser Benutzer

nach seiner Einrichtung noch deaktiviert. Um ihn zu aktivieren, setzen Sie

den Profilparameter login/no-automatic-user-sapstar auf den Wert 0.

Die Änderung kann über Transaktion RZ10 erfolgen.

Um eine Mandantenkopie zu erstellen, müssen Sie sich im neuen Mandan-

ten mit dem Benutzer SAP* anmelden. Die Transaktion für eine Mandan-

tenkopie ist SCCL. Nach der Ersteinführung eines SAP-Systems dient der

Mandant 000 als Referenzmandant. Über Transaktion SCC3 kann die Man-

dantenkopie überwacht werden.

Tabelle T000Über Transaktion SCC4 kann ein Mandant angelegt und mit Attributen ver-

sehen werden. Diese Attribute legen fest, welche grundsätzlichen Aktivitä-

ten unter einem Mandanten erlaubt sind. Die Attributeinstellungen

3 Mandanten

74

bringen die Mandantenrollen erst zum Leben. Die Einträge werden in der

Datenbanktabelle T000 gespeichert.

Attribute eines

Mandanten

Die wichtigsten Attribute sind die folgenden (siehe auch Abbildung 3.2):

� Vorschlagswährung für den Mandanten, z. B. EUR

� Mandantenrolle

� mandantenabhängige Änderbarkeit

� mandantenunabhängige Änderbarkeit

� Mandantenschutz

Abbildung 3.2 Transaktion SCC4: Eigenschaften eines Mandanten

3.2.1 Änderungen und Transporte für mandantenabhängige Objekte

Customizing Über diese Einstellung wird festgelegt, ob Änderungen an mandanten-

abhängigen Daten (Customizing) zugelassen sind. Hier noch einmal der


75

3

Hinweis: Bei diesen Daten handelt es sich nicht um Anwendungsdaten

oder Betriebsdaten, wie sie bei einem Anwendungsprogramm anfallen, z. B.

Kundendaten oder Daten aus einer Auftragserfassung. Es gibt folgende Ein-

stellmöglichkeiten (siehe Abbildung 3.3):

� Änderungen ohne automatische Aufzeichnung, d. h., diese Änderungen

werden nicht automatisch in einen Transport geschrieben, das kann

aber manuell nachgeholt werden. Allerdings kann es hier zu Problemen

kommen, da Einträge in den manuellen Erfassungen vergessen werden

können.

� Automatische Aufzeichnung von Änderungen, was natürlich eine Änder-

barkeit impliziert. Dies wäre eine Option für einen Entwicklungsman-

danten in einem Entwicklungssystem.

� Keine Änderungen erlaubt. Dies wird in einem produktiven System ein-

gestellt sein.

� Änderungen ohne automatische Aufzeichnung, keine Transporte er-

laubt. Änderungen sind erlaubt, werden aber nicht aufgezeichnet, und es

ist auch kein Transport zulässig. Dies wäre in einem Spielsystem für Ent-

wickler sinnvoll.

Abbildung 3.3 Transaktion SCC4: Einstellmöglichkeiten für die

Änderbarkeit von mandantenabhängigen Objekten

Beachten Sie, dass Repository-Objekte (z. B. Programme, Tabellendefini-

tionen) mandantenunabhängig und damit von dieser Einstellung nicht

betroffen sind.

3.2.2 Änderungen an mandantenübergreifenden Objekten

CustomizingVon dieser Einstellung sind Repository-Objekte und mandantenunabhän-

giges Customizing betroffen. Auch hier gibt es vier Einstellmöglichkeiten

(siehe Abbildung 3.4):

� Änderungen an Repository und mandantenunabhängigem Customizing

erlaubt (dies trifft auf Entwicklungssysteme mit Entwicklungsman-

danten zu)

3 Mandanten

76

� Keine Änderung von mandantenunabhängigen Customizing-Objekten

erlaubt

� Keine Änderung an Repository-Objekten erlaubt

� Keine Änderung von Repository- und mandantenunabhängigem Custo-

mizing-Objekten erlaubt. Diese Einstellung wird für Qualitätstest- und

Produktionsmandanten empfohlen. Der letzte Punkt fasst die zweite

und dritte Einstellmöglichkeit zusammen.

Abbildung 3.4 Transaktion SCC4: Einstellmöglichkeiten für Änderungen

an mandantenübergreifenden Objekten

3.2.3 Mandantenschutz und Vergleichstool

Mandantenschutz Bei dieser Einstellung geht es um den allgemeinen Mandantenschutz. Es

gibt drei Schutzstufen, die in Abbildung 3.5 gezeigt werden.

Abbildung 3.5 Transaktion SCC4: einstellbare Schutzstufen beim Mandanten

� Schutzstufe 0: keine Beschränkung

� Schutzstufe 1: kein Überschreiben

Hier wird der Mandant vor dem Überschreiben durch eine Mandanten-

kopie geschützt. Diese Einstellung bietet sich bei einem Produktivman-

danten und auch bei einem Entwicklungsmandanten an, bei dem das

Customizing nicht überschrieben werden soll.

� Schutzstufe 2: kein Überschreiben, keine externe Verfügbarkeit

Bei Schutzstufe 2 kommt zusätzlich die Einschränkung hinzu, ob ein

Mandant als Vorlage für eine Mandantenkopie herangezogen werden

kann. Über diese Einstellung wird ein Lesezugriff auf den Mandanten

verhindert. Die negative Einstellung wäre bei einem Mandanten mit

sensitiven Daten, die nicht weitergegeben werden sollen, sinnvoll.


77

3

3.2.4 Einschränkungen beim Starten von CATT und eCATT

CATT (Computer Aided Test Tool) ermöglicht das automatische Durchspie-

len von Testfällen, was Änderungen in der Datenbank zur Folge haben

kann. In einem produktiven System wäre dies ein negativer Nebeneffekt.

Mit diesem Attribut können Sie einschränken, inwieweit CATT/eCATT

(Extended CATT) für einen Mandanten zugelassen ist oder nicht (siehe

Abbildung 3.6).

Abbildung 3.6 Transaktion SCC4: Einschränkungen

für CATT/eCATT

3.2.5 Weitere Einschränkungen

Als Letztes sind noch folgende Einschränkungen einstellbar (siehe Abbil-

dung 3.7):

� Wegen Mandantenkopie gesperrt

Wenn von diesem Mandanten gerade eine Kopie erzeugt wird, so soll er

für diese Zeit komplett gesperrt werden.

� Schutz gegen SAP-Upgrade

Hiermit wird ein Mandant von einem SAP-Upgrade ausgenommen.

Damit ist ein nachfolgender Negativtest möglich, d. h., es wird getestet,

ob die Anwendungssoftware nach dem Upgrade noch genauso funktio-

niert wie vor dem Upgrade.

Abbildung 3.7 Transaktion SCC4: weitere Einschränkungen

79

4

Kapitel 4

SAP-Berechtigungen

In diesem Kapitel ...

... lernen Sie:

� was Berechtigungen sind

� wie Sie Berechtigungen festlegen

� wie Sie die Benutzer im SAP-System verwalten

Berechtigungen werden verwendet, um zu kontrollieren, wer Daten einse-

hen und verändern darf, und dienen damit gleichzeitig dazu, die vorhande-

nen Daten zu schützen. SAP bietet ein sehr umfangreiches Berechtigungs-

system, mit Hilfe dessen bis auf Feldebene Berechtigungen erteilt werden

können.

4.1 Rollen und Berechtigungen

Berechtigungs-

objekt

Eine Berechtigung ist eine Erlaubnis, eine bestimmte Funktionalität in einem

Anwendungssystem auszuüben. Grundlage einer Berechtigung ist ein Be-

rechtigungsobjekt. Für ein Berechtigungsobjekt wird eine Berechtigung

festgelegt. Was genau ein Berechtigungsobjekt ist, wird in einem Berechti-

gungskonzept definiert. Dies kann z. B. die Abwicklung einer Wertpapier-

transaktion sein, die Pflege von Wertpapiergattungsdaten oder die Einsicht

in Kundendepots einer Bank.

BerechtigungsfelderEinem Berechtigungsobjekt können bis zu 10 Berechtigungsfelder zugeord-

net werden. Berechtigungsfelder sind ebenfalls Gegenstand des Berechti-

gungskonzepts. Über Berechtigungsfelder legen Sie fest, welche Ausfüh-

rungsaktivitäten bei einem Berechtigungsobjekt grundsätzlich möglich

sind. SAP bietet über Transaktion SU20 eine Reihe vordefinierter Berechti-

gungsfelder an, die Sie bei der Anlage eines Berechtigungsobjekts nutzen

können (siehe Abbildung 4.1). Sie können hierüber auch eigene Berechti-

gungsfelder anlegen.

4 SAP-Berechtigungen

80

Abbildung 4.1 Transaktion SU20: Berechtigungsfelder

Bei der Abfrage nach einer Berechtigung werden die Berechtigungsfelder

über eine UND-Verknüpfung abgefragt. Beispiel: Darf ein Benutzer das

Wertpapiersystem aufrufen, und darf der Benutzer eine Wertpapiertrans-

aktion durchführen, und darf der Benutzer dazu Einsicht in die Depots von

Geschäftskunden haben?

Berechtigungsfeld

ACTVT

Die einzelnen Berechtigungsfelder enthalten einen Wertebereich, über den

Aktivitäten gesteuert werden. Alle Berechtigungsfelder haben als Grund-

lage ein Datenelement, über dessen Wertebereich die möglichen Werte von

Berechtigungsfeldern festgelegt werden (Datenelemente stellen wir Ihnen

in Abschnitt 5.2.1 vor). Daneben ist es aber auch möglich, dass Berechti-

gungsfelder ihre Wertigkeiten zur Laufzeit aus gepufferten Tabellen im

internen Speicher erhalten. Ein von SAP vordefiniertes Berechtigungsfeld,

ACTVT, wird dabei sehr häufig verwendet. Dessen Wertebereich ist sehr um-

fangreich, so dass sich darüber bereits zahlreiche unterschiedliche Berech-

tigungen abdecken lassen (siehe Abbildung 4.2).

Vordefinierte

Berechtigungs-

objekte

Neben vorgefertigten Berechtigungsfeldern bietet SAP vordefinierte Be-

rechtigungsobjekte an. Diese rufen Sie über Transaktion SU21 auf. Über

diese Transaktion können Sie auch eigene Berechtigungsobjekte anlegen

(siehe Abbildung 4.3). Berechtigungsobjekte lassen sich in Berechtigungs-

klassen zusammenfassen.


81

4

Abbildung 4.2 Ausschnitt der Berechtigungswerte

des Berechtigungsfelds ACTVT

Abbildung 4.3 Transaktion SU21: Berechtigungsobjekte


82

PFCG Benutzern werden diese Berechtigungsobjekte nicht direkt zugeordnet,

sondern indirekt, indem eine Benutzerkennung mit einer Rollendefinition

verknüpft wird. Dies geschieht über Transaktion PFCG, mit der Sie Berechti-

gungsrollen neu anlegen und pflegen.

Rollenmenü Eine Rolle ist mit einer oder mehreren Aktivitäten in einem SAP-System

verbunden. Die Ausgestaltung dieses rollendefinierten Benutzermenüs ist

der erste Schritt bei der Neuanlage einer Rolle in Transaktion PFCG.

Abbildung 4.4 zeigt Ihnen beispielhaft das Rollenmenü (Benutzermenü) für

die von SAP vordefinierte Rolle SAP_BC_AUTH_DATA_ADMIN für einen Berechti-

gungsverwalter.

Abbildung 4.4 Transaktion PFCG: Rollenmenü

In Abbildung 4.4 sehen Sie, dass dem Menüpunkt Benutzer Transaktion

SU01 zugeordnet ist. Diese Zuordnung erreichen Sie über den Button

. Sie können einen Menüpunkt nicht nur mit einem Transak-

tionscode verbinden, sondern z. B. auch mit einem Programm oder Querys.

Die möglichen Berechtigungen zu den Menüpunkten dieser Rolle legen Sie

im Tab Berechtigungen fest (siehe Abbildung 4.5).

Im unteren Teil des Bildes gibt es den Bereich Berechtigungsdaten pflegen

und Profile generieren. Wenn Sie dort auf das Icon klicken, werden

Ihnen die festgelegten Berechtigungen angezeigt (siehe Abbildung 4.6).


83

4

Abbildung 4.5 Transaktion PFCG: Berechtigungen festlegen

Abbildung 4.6 Transaktion PFCG: festgelegte Berechtigungen zur Rolle

Ganz rechts sehen Sie die Berechtigungsfelder und in der Mitte die berech-

tigte Aktivität. Für das Berechtigungsobjekt Aktivität der Benutzerstamm-

pflege: Berechtigungen sind es in diesem Fall 03 = 'Anzeigen' und 08 =

'Änderungsbelege anzeigen' aus dem Wertebereich des Berechtigungsfeldes

ACTVT. Die Namen der Berechtigungsfelder bekommen Sie angezeigt, wenn

Sie auf den Menüpunkt Hilfsmittel � Technische Namen ein klicken.


84

Berechtigungsprofil Damit die Berechtigungen wirksam werden, müssen Sie ein Profil gene-

rieren. Dazu klicken Sie in Abbildung 4.5 auf das Icon . Das System

erzeugt ein Profil und zeigt dessen Namen im Feld Profilname an (siehe

Abbildung 4.7).

Abbildung 4.7 Transaktion PFCG: generierter Profilname

Als Letztes müssen Sie der Rolle einen Benutzer hinzufügen. Dazu wechseln

Sie in Transaktion PFCG in den Tab Benutzer. Im Bereich Benutzerzuord-

nungen tragen Sie in der Spalte Benutzerkennung den oder die gewünsch-

ten Benutzer ein (siehe Abbildung 4.8).

Abbildung 4.8 Transaktion PFCG: einer Rolle einen Benutzer zuordnen

Klicken Sie anschließend auf den Button . Dadurch wird

für den Benutzer die Rolle in der Benutzerverwaltung (siehe Abschnitt 4.2)

eingetragen. Die grüne Farbe im Button signalisiert den Erfolg des Eintrags.

Über Transaktion SU02 können Sie sich die Berechtigungsprofile im Detail

anschauen. In früheren Zeiten wurden Berechtigungen auf diesem Wege

definiert. Das Berechtigungsprofil wurde dann nicht einer Rolle zugeord-

net, sondern direkt einem Benutzer in der Benutzerverwaltung. SAP emp-

fiehlt, diesen Weg nicht mehr zu beschreiten, sondern Berechtigungen

über die Rollenverwaltung PFCG festzulegen.

Berechtigungs-

prüfung

Sie können in einem Programm gleich zu Beginn eine Berechtigungsprü-

fung durchführen. Für produktive Batchverarbeitungen gibt es oftmals in

4.2 Benutzerverwaltung

85

4

Unternehmen einen Batchuser, dem allein das Recht zugeteilt wurde,

bestimmte Batchverarbeitungen durchzuführen. Mit dem ABAP-Programm

aus Listing 4.1 fragen Sie die Berechtigung ab:

Authority-Check Object <Berecht.Objekt>FOR USER <user>

ID <Berecht.Feld1> field <Berecht.Wert>ID <Berecht.Feld2> field <Berecht.Wert>.

IF sy-subrc <> 0.Message ..... TYPE 'E'.ENDIF.

Listing 4.1 Berechtigungen abfragen


Transaktion SU01 ist die zentrale Transaktion zur Verwaltung der Benutzer.

Jeder Benutzer, der in einem SAP-System arbeiten möchte, muss über diese

Transaktion registriert sein. Hier werden Benutzer im SAP-System ange-

legt, verwaltet und auch wieder gelöscht. Die Transaktion ist in mehrere

Reiter unterteilt, mit Hilfe derer ein Benutzer verwaltet wird (siehe Abbil-

dung 4.9).

Abbildung 4.9 Transaktion SU01: Benutzerverwaltung

EinstellungenDie wichtigsten Tabs dieser Transaktion sind:

� Adresse: Hier werden persönliche Daten des Benutzers eingetragen.

� Logondaten: In diesem Tab werden das Kennwort, der Gültigkeitszeit-

raum des Kennworts und eine mögliche Abrechnungsstelle verwaltet.


86

� Festwerte: Dieser Tab dient der Festlegung von bestimmten Formaten

und der Anmeldesprache (siehe Abbildung 4.10). Zu den Formaten gehö-

ren die Dezimaldarstellung, die Datumsdarstellung und das Zeitformat.

Abbildung 4.10 Transaktion SU01: Festwerte

� Parameter: Hierüber können für bestimmte Systemparameter Grund-

werte festgelegt werden, z. B., dass ein lokales Objekt standardmäßig dem

Paket $TMP zugewiesen wird (zu lokalen Objekten und Paketen siehe

Abschnitt 6.1).

� Rollen: Hier sind die dem Benutzer zugeteilten Rollen eingetragen. In

Abschnitt 4.1, »Rollen und Berechtigungen«, haben wir Ihnen die Rollen-

verwaltung PFCG vorgestellt und zu Demonstrationszwecken dem Be-

nutzer Testuser die Rolle SAP_BC_AUTH_DATA_ADMIN zugewiesen. Diese

Rolle sehen Sie nun in Abbildung 4.11.

Abbildung 4.11 Transaktion SU01: zugeteilte Rollen


87

4

� Profile: Rollen vereinigen Berechtigungsprofile. Diese finden Sie unter

diesem Reiter. Das generierte Profil zur neu hinzugefügten Rolle der

Berechtigungsverwaltung ist hier ebenfalls eingetragen (siehe Abbil-

dung 4.12).

Abbildung 4.12 Transaktion SU01: Profile zur Berechtigung

BenutzermenüsDie neu hinzugefügte Rolle der Berechtigungsverwaltung ist über ein

Benutzermenü definiert (siehe auch Abbildung 4.4). Dieses Benutzermenü

ist nun Teil des gesamten Benutzermenüs für den Benutzer TESTUSER (siehe

Abbildung 4.13).

Abbildung 4.13 Erweitertes Benutzermenü zur Rolle


88

Neben Transaktion SU01 gibt es die folgenden Transaktionen:

� SUIM: Benutzerinformationssystem

� SU10: Massenänderungen zur Benutzerpflege

Zentrale Benutzer-

verwaltung

Des Weiteren können Sie eine zentrale Benutzerverwaltung über eine SAP-

Systemlandschaft hinweg aufbauen. Hierfür sind die folgenden Transaktio-

nen von Bedeutung:

� SM59: RFC-Verbindungen

� SCUA: Pflege der Systemlandschaft

� SCUM: Zentrale Benutzerverwaltung

� SCUG: Benutzerübernahme

� SUGR: Benutzergruppen pflegen

� SCUL: Protokollanzeige der zentralen Benutzerpflege

Wie Sie eine zentrale Benutzerverwaltung einrichten, ist anschaulich in

Sebastian Schreckenbach, Praxishandbuch SAP Administration, SAP PRESS

Bonn 2015, S. 592 ff beschrieben.

sap – der technische einstieg · ein programm abgefragt werden kann. ddic der standardbenutzer...

Documents