SAP-Mandant anlegen und löschen: SCC4 und SCC5

Neuen SAP-Mandanten in SCC4 anlegen

Ein Mandant ist in SAP zunächst nur ein Eintrag in der Tabelle T000. Gepflegt wird sie mit der Transaktion SCC4 (Mandantenverwaltung). So legen Sie einen neuen Mandanten an:

Logisches System bereitstellen. Soll der Mandant Daten mit anderen Systemen austauschen, legen Sie seinen logischen Systemnamen vorher in BD54 an, nach der üblichen Konvention zum Beispiel QASCLNT200.
SCC4 öffnen. Die Mandantenübersicht erscheint im Anzeigemodus. Mit Anzeigen ↔ Ändern wechseln Sie in den Änderungsmodus.
Neue Einträge wählen. Mandantennummer, Bezeichnung, Ort, logisches System und Standardwährung eintragen.
Rolle, Änderungsoptionen und Schutz setzen. Passend zum Zweck des Mandanten. Was die Felder bedeuten, zeigt der nächste Abschnitt.
Sichern. Der Mandant steht jetzt in der Mandantentabelle T000. Mehr ist er noch nicht: Customizing, Anwendungsdaten und Benutzer fehlen.
Befüllen. Den Mandanten per Mandantenkopie füllen und danach die Nacharbeiten erledigen.

Der neue Mandant ist leer. Erst die Kopie bringt Customizing, Benutzer und auf Wunsch Anwendungsdaten hinein. Welche Mandanten in welches System gehören, beschreibt der Artikel Mandantenkonzept und Systemlandschaft.

Die Einstellungen in SCC4

Die Detailsicht eines Mandanten in SCC4 enthält diese Felder. Die ersten vier beschreiben den Mandanten, die übrigen steuern, was in ihm erlaubt ist.

Feld	Was es festlegt
Mandant	Dreistellige Nummer, die im System noch nicht vergeben ist. 000 ist der SAP-Referenzmandant.
Bezeichnung und Ort	Freitext zur Orientierung, zum Beispiel „QS Finanzen“ und „Hamburg“.
Logisches System	Name des Mandanten als Kommunikationspartner, etwa für ALE und IDocs. Optional, aber nötig, sobald der Mandant Daten mit anderen Systemen austauscht.
Standardwährung	Währungsschlüssel des Mandanten, zum Beispiel EUR.
Mandantenrolle	Produktiv, Test, Customizing, Demo, Schulung/Ausbildung oder SAP-Referenz.
Änderungen und Transporte für mandantenabhängige Objekte	Ob Customizing in diesem Mandanten geändert werden darf und ob die Änderungen automatisch in Transportaufträgen landen.
Mandantenübergreifende Objekte	Ob aus diesem Mandanten heraus Repository-Objekte und mandantenübergreifendes Customizing geändert werden dürfen.
Schutz: Mandantenkopierer und Vergleichstool	Ob der Mandant überschrieben oder als Quelle für Kopien und Vergleiche genutzt werden darf.
Einschränkungen für CATT und eCATT	Ob Testskripte mit eCATT oder dem Vorgänger CATT im Mandanten laufen dürfen, auf Wunsch nur über Trusted RFC.

Mandantenrolle

Die Rolle beschreibt den Zweck des Mandanten, und sie wirkt. SAP-KBA 2391632 beschreibt den Fall, dass SCCL, SCC9 oder SCC1 in einem Mandanten mit der Rolle Produktiv abbrechen: Meldung TA133, der Zielmandant sei produktiv und gegen Mandantenkopie geschützt. Vergeben Sie die Rolle Produktiv deshalb nur an den echten Produktivmandanten und die Rolle Test an QS- und Testmandanten.

Änderungen und Transporte für mandantenabhängige Objekte

Automatische Aufzeichnung von Änderungen: Jede Customizing-Änderung landet in einem Transportauftrag. Das ist die Einstellung für den Customizing-Mandanten im Entwicklungssystem.
Änderungen ohne automatische Aufzeichnung: Änderungen sind erlaubt, landen aber nicht automatisch in einem Transportauftrag.
Keine Änderungen erlaubt: Customizing kommt nur per Transport in den Mandanten. Üblich für Produktiv- und QS-Mandanten.
Änderungen ohne automatische Aufzeichnung, keine Transporte erlaubt: Änderungen bleiben im Mandanten und lassen sich auch manuell nicht transportieren. So bleibt ein Spielmandant sauber vom Transportweg getrennt.

Mandantenübergreifende Objekte

Repository-Objekte wie Programme und Tabellendefinitionen sowie mandantenübergreifendes Customizing gelten für alle Mandanten eines Systems. Eine Änderung in einem Mandanten wirkt sofort in allen anderen. SCC4 bietet vier Stufen: beides erlaubt, nur mandantenübergreifendes Customizing gesperrt, nur das Repository gesperrt oder beides gesperrt. Erlauben Sie solche Änderungen nur im Customizing-Mandanten des Entwicklungssystems.

Schutz gegen Mandantenkopierer und Vergleichstool

Stufe 0, keine Beschränkung: Der Mandant darf überschrieben, kopiert und verglichen werden.
Stufe 1, kein Überschreiben: Der Mandant bleibt Quelle für Kopien und Vergleiche, lässt sich aber nicht überschreiben. Üblich für Produktivmandanten.
Stufe 2, kein Überschreiben und keine Außenverfügbarkeit: Zusätzlich kann ihn niemand als Quelle für Kopien oder Vergleiche nutzen.

Anmeldung im neuen Mandanten: SAP* und Profilparameter

Ein frisch angelegter Mandant hat noch keine Benutzer. Die klassischen Werkzeuge SCCL und SCC9 starten Sie aber im Zielmandanten. Dafür ist der Benutzer SAP* gedacht. Gibt es in einem Mandanten keinen Benutzerstammsatz für SAP*, greift ein fest im System hinterlegter Benutzer dieses Namens: Kennwort PASS, keine Berechtigungsprüfung, also alle Rechte.

Standardmäßig ist diese Anmeldung gesperrt, und zwar über den Profilparameter login/no_automatic_user_sapstar. Für eine klassische Kopie setzen Sie ihn vorübergehend auf 0 und starten den Applikationsserver neu.

Sicherheitsrisiko. Der Parameter gilt nicht für einen einzelnen Mandanten, sondern für alle. Solange er auf 0 steht, kann sich in jedem Mandanten ohne Benutzerstammsatz für SAP* jeder mit dem bekannten Kennwort anmelden und hat dort alle Berechtigungen. Halten Sie dieses Fenster so kurz wie möglich.

Nach der Kopie den Parameter wieder aktivieren (Wert 1) und den Applikationsserver erneut starten
SAP* nicht löschen: SAP empfiehlt, in jedem Mandanten einen Benutzerstammsatz für SAP* anzulegen, ihn der Benutzergruppe SUPER zuzuordnen und ihm bis auf die Lizenzverwaltung alle Berechtigungen zu entziehen
Für Notfälle einen eigenen Superuser vom Typ Service mit einer Notfallrolle für die Benutzerverwaltung anlegen, statt mit SAP* zu arbeiten

Ab SAP_BASIS 7.54, also ab S/4HANA 1909, geht es ohne diesen Umweg. Die neuen Werkzeuge wie SCCLN und SCC9N müssen nicht im Zielmandanten laufen. SAP empfiehlt, sie aus einem dritten, nicht beteiligten Mandanten zu starten, zum Beispiel aus 000. SAP* und der Neustart entfallen. Was die neuen Werkzeuge sonst ändern, zeigt der Artikel zu SCCLN, SCC9N und SCC1N.

Den neuen Mandanten befüllen

Was in den Mandanten kommt, bestimmt die Mandantenkopie: lokal aus einem Mandanten desselben Systems, remote aus einem anderen System oder per Export und Import. Das Kopierprofil legt fest, ob nur Customizing, zusätzlich die Benutzer oder auch die Anwendungsdaten übertragen werden. Beides erklärt der Grundlagenartikel zur SAP-Mandantenkopie.

Erster Mandant eines neuen Systems: Kopie aus dem Referenzmandanten 000 mit dem Profil SAP_CUST. Die Anwendungsdaten in 000 sind nicht garantiert konsistent und gehören nicht in den neuen Mandanten.
Weiterer Mandant im selben System: lokale Kopie, etwa für einen Schulungs- oder Testmandanten.
QS- oder Testmandant mit produktionsnahen Daten: Kopie aus der Produktion. Danach müssen die logischen Systemnamen umgesetzt werden, siehe BDLS nach System- und Mandantenkopie.

Ab SAP_BASIS 7.54 schätzt die Transaktion SCC_CLIENT_SIZE vorab, wie viel Platz die Kopie braucht. Das lohnt sich, denn in SAP HANA liegen die kopierten Daten im Hauptspeicher. Die Kopierläufe prüfen Sie in SCC3, danach folgen die Nacharbeiten nach der Kopie.

SAP-Mandant löschen: SCC5 und SCC5N

Mandanten, die niemand mehr braucht, belegen Speicher und müssen trotzdem abgesichert werden. Löschen Sie sie mit den Werkzeugen der Mandantenverwaltung. Was Sie noch brauchen, sichern Sie vorher, etwa per Mandantenexport.

Klassisch mit SCC5: Sie melden sich in dem Mandanten an, den Sie löschen wollen, und starten SCC5. Optional entfernen Sie den Eintrag aus T000 gleich mit, sonst bleibt der leere Mandant in SCC4 stehen. Parallele Prozesse verkürzen die Laufzeit.

Ab SAP_BASIS 7.54 mit SCC5N: Hier müssen Sie sich nicht im betroffenen Mandanten anmelden, sondern wählen ihn aus einer Liste. Auch SCC5N fragt, ob der Eintrag in T000 mit gelöscht wird. Dazu kommen ein Testmodus, parallele Prozesse und der Start als Hintergrundjob.

Die SAP-Hilfe weist darauf hin, dass der frei gewordene Platz in den meisten Datenbanken erst nach einer Reorganisation verfügbar ist. Planen Sie das ein, wenn Sie mit dem Löschen Speicher gewinnen wollen.

Typische Fehler und Fallstricke

Kopie bricht sofort ab: Der Zielmandant hat die Rolle Produktiv oder eine Schutzstufe, die Überschreiben verbietet. Prüfen Sie in SCC4, ob das Absicht ist, bevor Sie etwas ändern.
SAP* bleibt offen: Der Profilparameter wurde für die Kopie auf 0 gesetzt und danach nicht zurückgestellt.
Logisches System fehlt oder ist doppelt vergeben: Belege und IDocs verweisen dann auf den falschen Partner. Nach jeder Kopie aus der Produktion die Namen in den Daten umsetzen.
Zu großzügige Änderungsoptionen: Darf im QS-Mandanten Customizing geändert werden, weichen QS und Produktion unbemerkt voneinander ab, und Tests verlieren ihre Aussagekraft.
Falscher Mandant gelöscht: SCC5 löscht immer den Mandanten, in dem Sie angemeldet sind. Prüfen Sie die Mandantennummer vor dem Start zweimal.
Vollkopie ohne Speicherplanung: Ein zusätzlicher Mandant mit allen Anwendungsdaten braucht in SAP HANA fast so viel zusätzlichen Hauptspeicher, wie der Quellmandant belegt.

Zielmandant vorbereiten, mit DRO befüllen

Anlegen, Rolle setzen, absichern: Das erledigen Sie in SCC4. Offen bleibt, womit Sie den Mandanten füllen. Die Standard-Mandantenkopie bringt mit den Anwendungsdaten immer die komplette Historie mit. Der Data Refresh Operator kopiert stattdessen eine Zeitscheibe, zum Beispiel die letzten 90 Tage, plus alle abhängigen Objekte aus älteren Jahren, aufgelöst bis zum Fixpunkt. Logische Systemnamen ersetzt DRO beim Import, bevor die Daten in die Datenbank geschrieben werden. Ein nachträglicher BDLS-Lauf entfällt.

Für den Schutz der Produktion arbeiten zwei Ebenen unabhängig voneinander. In DRO verhindern Systemrollen Importe in die Produktion. In SAP sorgen die Mandantenrolle Produktiv und die Schutzstufe in SCC4 dafür, dass die Standardwerkzeuge den Produktivmandanten nicht überschreiben. Pflegen Sie beide, dann hängt der Schutz nicht an einer einzigen Einstellung.

Playbooks automatisieren den Ablauf drumherum: Jobs anhalten, Benutzer sperren, Benutzerstämme sichern, importieren, kundenspezifische Nacharbeiten erledigen. DRO läuft ab SAP S/4HANA 2023 und ersetzt die Mandantenkopie, nicht die Systemkopie. Wie ein solcher Ablauf aussieht, zeigt das Beispiel-Playbook.

Quellen

SAP PRESS Blog, 17.11.2023: How to Create Clients in an SAP S/4HANA System
SAP-Hilfe: Mandantenkopierer: Zielmandant, Benutzer SAP* und Profilparameter (SAP NetWeaver 7.3)
SAP-Hilfe: Securing User SAP* Against Misuse
SAP-Hilfe: Mandanten löschen (SAP NetWeaver 7.3)
SAP Learning: Client Copy and Client Transport Tools (SCCLN, SCC9N, SCC5N, SCC_CLIENT_SIZE)
SAP-KBA 2391632: TA133: Target client is productive and protected against client copy (SAP-Support-Portal, Anmeldung nötig)

SAP-Mandant anlegen, löschen und in SCC4 einstellen