„The client“ – Grishams Klassiker rund um die Mafia ist durchaus lesenswerter Stoff für Thriller-Fans. Der Stoff, aus dem hingegen die Administratorenalbträume sein können, hat manchmal leider auch mit Clients zu tun : das „Client Management“. Um das sprichwörtliche Buch zumindest von einigen Siegeln zu befreien, anbei ein Kurzüberblick.
Mandanten?
Viele wundern sich beim Erstkontakt über diesen Begriff “clients”. Dieser ist historisch gewachsen, man muss nur wissen woher er kommt. Ungefähr zu der Zeit als Bill Gates angeblich das Zitat „640 kB ought to be enough for anybody.“ (1981 – also sehr lang her, und auch mehrfach dementiert) prägte, entschied sich die SAP ein System zu kreieren was „mehrmandantenfähig“ ist.
Basierend auf der Annahme, ein Mainframe-Server sei stark genug für mehrere Kunden und oft zu teuer für einen einzigen, ersann man die Idee „betriebswirtschaftlich“ abgegrenzte Teileinheiten in einem SAP-System unterzubringen. Praktisch packt man also mehrere Kunden in ein System, spart Geld für teure Hardwareressourcen und schont den Markt für Systemadministratoren. Das Hosting war geboren.
Die Folge : Ein SAP-System hat
– eine einzige Datenbank,
– nur einen Kernel (technische Verbindung zur Datenbank),
– eine einzige (DEFAULT-) Parameterisierung, und
– in der Datenbank
o eine einzige mandantenübergreifende Systemkonfiguration (cross client customizing)
o R/3 Repository (Typen, Reports, Tabellenstrukturen, usw.)
Jeder Mandant für sich hat in diesem globalen SAP-Rahmen:
– eigene Konfigurationsseinstellungen (= client dependent customizing),
– eigene mandantenabhängige Tabelleninhalte (Application Data),
– einen eigenen Benutzerstamm, und
– als wichtiges Konfigurationsmerkmal : ein logisches System.
Heutzutage hat sich durchgesetzt, jedem Kunden sein eigenes System zu spendieren, oft auch mit mehreren Mandanten für diesen einen Kunden die verschiedene Zwecke erfüllen. Geschäftsprozesse werden zumindest in großen Unternehmen so gut wie immer sogar über mehrere Systemlandschaften aufgeteilt (HR, FI, usw.). Das kommt auch der Produktphilosophie der SAP entgegen, Funktionen in eigene Produkte auszulagern (PI, BW, Portal usw.).
Allerdings findet sich in der freien Wildbahn auch der ein oder andere Dienstleister, der „Client Hosting“ erfolgreich anbietet. Das ist einigen Restriktionen unterworfen (ich muss mich über Kennwortlängen mit den anderen Kunden abstimmen), aber auch heute noch technisch problemlos realisierbar.
Wie geht man mit Mandanten um?
Die Abbildung der Mandanten in der gemeinsamen Datenbank geschieht über Mandantenschlüssel in den Tabellen (Mandantenschlüssel existiert => mandantenabhängige Tabelle). Die Schlüssel selbst werden in der Tabelle T000 gepflegt :
Eine Mandantenkopie oder ein –export erzeugt folgerichtig im Ziel ein Abbild nur jener Tabellen die einen Mandantenschlüssel enthalten (mandantenabhängig), und jener Zeilen aus diesen Tabellen die mit dem angegebenen Schlüssel übereinstimmt. Ausgenommen hiervon sind die unpraktischen Tabellen (weil groß und im Ziel weitgehend nutzlos), wie bspw. Änderungsbelege. Diese werden von den SAP Tools standardmäßig nicht kopiert.
Da ein Mandant Teil einer auf ihn abgestimmten Systemumgebung ist (siehe oben), muss dringend davon abgeraten werden Mandanten zu ernsthaften Zwecken zwischen heterogenen Systemlandschaften hin- und her- zu kopieren (Release! Repository! Customizing!). Oft möchte man jedoch innerhalb einer homogenen Landschaft in Testsystemen temporär eine zweite, unabhängige Datenumgebung schaffen. Oder man will schlicht nur die Daten aus der Produktion in die Testumgebung spiegeln, ohne das Zielsystem vollständig zu überschreiben.
Die Mandantenkopierfunktionen sind in diesen homogenen Umgebungen sehr nützlich, wenn
- es sich um kleinere Datenmengen handelt (besser < 100GB, keinesfalls > 500GB)
- aus bestimmten Gründen die mandantenunabhängigen Inhalte des Ziels erhalten bleiben müssen.
- Bspw. nur User in einen bestehenden Mandanten übertragen werden sollen.
- Keine vollständige Datenkonsistenz benötigt wird, oder das Quellsystem nicht verwendet wird.
- Der Releasestand identisch ist (Export-System > Import-System geht technisch, macht aber in der Nachbereitung schwere Probleme und sollte daher auf keinen Fall durchgeführt werden)
In allen anderen Fällen empfiehlt sich schlicht eine Systemkopie (kürzere Laufzeit, weniger Aufwand, in sich konsistent, Quellsystem wird nicht belastet).
Die Mandantenverwaltung
SCC3 Mandantenprotokolle
Zentrale Anlaufstelle, wenn man Protokolle zur Mandantenverwaltung sucht. Bitte auch Buttons am oberen Rand beachten („Alle Mandanten“, „Exporte“). Achtung : beim Import gibt’s hier erst ein Protokoll wenn der technische Import fertig ist, und die Nachbereitung begonnen wurde. Bis dahin hat nämlich das TMS das Sagen, und es muss dort gemonitored werden.
SCC4 Anlage, Pflege von Mandanten.
Pflege der Tabelle T000, unter anderem Status, Schutzstufe (Customizing / Repository aus diesem Mandanten änderbar; Überschreibbarkeit durch Mandantenkopie; Löschen erlaubt usw.) einstellbar. Auch Währung und logisches System werden hier gepflegt.
SCC5 Mandanten löschen.
Wird ein Mandant nicht mehr benötigt, kann er hier gelöscht werden. Auch nützlich für Carve Out Projekte, bei denen einzelne Unternehmensteile ausgegliedert werden, und ihren Mandanten “mitnehmen” (Systemkopie –> übrige Mandanten löschen –> ggf. Datenbank-Reorganisation –> Migrationsexport).
SCC7 Nachbereitung eines Mandantenimports.
Immer dann nötig, wenn das Transportwesen (TMS) bemüht wird, um Mandanten von A nach B zu bringen. Ist nach Abschluss des Imports die Nachbereitung direkt im importierten Mandanten zu starten.
SCC8 Mandantenexport.
Verwendet das TMS um Mandanten in das Filesystem zu exportieren. Angabe eines der Kopierprofile nötig. Vor Export Platz im Filesystem prüfen, Transportverzeichnisse sind normalerweise ohne Anpassungen nicht geeignet 500GB große Mandanten zu beherbergen. Es wird komprimiert, aber oft nicht wesentlich.
SCC9 Remote Mandantenkopie (RFC)
Voraussetzung : funktionierende RFC Verbindung zur Quelle, externe Verfügbarkeit konfiguriert (SCC4), Mandant nicht zu groß, Quellsystem kann Kopier-Last vertragen, Quelle und Ziel haben ausreichend große rdisp/max_wprun_time. Achtung : man zieht die Daten, was heißt die SCC9 wird im Ziel gestartet.
SCCL – Lokale Mandantenkopie
Wird gern im Aufbau neuer Systeme verwendet. Kopiert Tabellen lokal (auch im Hintergrund möglich anhand eines der Kopierprofile. Für Leeraufbau eines neuen Mandanten bspw. SAP_CUST mit Quellmandant 000 (Achtung, war früher mal 001).
STMS_IMPORT
Die Transaktion der lokalen Importqueue, hier können unter anderem Mandantenimporte gestartet und überwacht werden. Nach Import muss zwingend die SCC7 ausgeführt werden, erst nach erfolgreichem Abschluss gilt der Mandant als vollständig importiert.
Weitere Begriffe
Ein Kopierprofil definiert immer die Menge der mandantenabhängigen Tabellen, die kopiert / exportiert werden. SAP_CUST bspw. kopiert nur Customizing (keine User), SAP_UCUS würde zusätzlich die User mitbringen. SAP_ALL kopiert den kompletten Mandanten, SAP_USER ausschließlich Benutzer und deren Berechtigungen. SAP_USER hat auch eine Spezialfunktion: alle anderen Profile leeren den Zielmandanten bei der Kopie, SAP_USER-Kopien jedoch lassen den Zielmandanten wie er ist, und überschreiben nur die Benutzerstämme und Rollen / Profile.
Ein logisches System definiert normalerweise innerhalb der Kundenlandschaften einen Mandanten eindeutig (Stichwort ALE). Mit seiner Hilfe lassen sich in Kommunikationsszenarien Belege noch einem Quellmandanten zuordnen. Da die SAP pro System eine SID empfiehlt, hat sich für den log. Namen der Standard gemäß PE5CLNT100 (oder wahlweise deutsch : PE5MNDT100) etabliert. Nach Mandantenkopien/Systemkopien kann je nach Zweck der Kopie eine Umsetzung des logischen Systems nötig sein (Anlage : BD54, Umsetzung : BDLS).
Tipps..
Die NRIV-Tabelle ist die zentrale Nummernkreistabelle (Transaktion SNUM) im SAP System. Dauert eine Mandantenkopie mehrere Tage, kann es sein dass nach Kopieren der NRIV (alle Tabellen A* bis N*) bis zum Abschluss der Kopie die Nummernkreise der Tabellen (O* bis Z*) bereits weitergelaufen sind – dann kann der manuelle Transport (von Kopien, SE01) der NRIV nötig sein.
Der Benutzer SAP* (pass) existiert als technischer User (im Kernel inbegriffen, kein Benuzterstammsatz in der DB nötig) in jedem leeren Mandanten (ob nun neu angelegt oder frisch gelöscht). Er wird benötigt, um in einem leeren Mandanten ohne Benutzerstammsätze überhaupt irgendetwas tun zu können. Voraussetzung für die Anmeldung mit diesem technischen User ist der Profilparameter login/no_automatic_user_sapstar = 1 (seit WebAS 6.20). Wird ein “richtiger” User Namen „SAP*“ im Mandanten angelegt, ist der technische SAP* nicht mehr aktiviert.
Wer lange kopiert und dann doch abbrechen will, hat unter Umständen mit verbleibenden Sperren zu kämpfen, die jede weiteren Mandantenverwaltungsaktion erfolgreich verhindern. Lösung : SM12 -> Tabelle „rstable“, Argument „rsclicopy“. Achtung bei Detailtext „backup“ nicht abbrechen (#43614).
RSCCEXPT ist ein Report zur Konfiguration von Mandantenkopien. Man kann hier einzelne Tabellen aussschließen (weil man sie gesondert kopiert, oder im Ziel nicht benötigt) und Parallelisierung konfigurieren, letzteres geht auch in vielen SCC-Transaktionen direkt (bspw. SCCL, SCC9).
Das Obligatorische
Diese Dokumentation ist eine Sammlung von Erfahrungswerten, und in keiner Form von den Produktherstellern (SAP, Oracle, ..) geprüft oder freigegeben worden. Es kann keine Haftung für Schäden übernommen werden, die aus dem (teilweisen oder vollständigen) Befolgen dieser Dokumentation entstehen.
Selbstverständlich freue ich mich über Fragen, Anmerkungen oder Ergänzungen.
