Tests lohnen sich bereits für die Einführung von SAP-Lösungen im Unternehmen und ebenso bei Release-Wechseln sowie Migrationsprojekten, beim Einspielen von Patches, bei Customizing, Modifikation und Eigenentwicklungen. Eine dreistufige SAP-Landschaft besteht typischerweise aus Entwicklungs-, Test- und Produktivsystemen. Dazu kommen oft noch Schulungssysteme.

Die verschiedenen Typen von SAP-Umgebungen müssen unterschiedliche Voraussetzungen erfüllen. Schulungen lassen sich beispielsweise nur dann zweckmäßig abhalten, wenn die Arbeitsbedingungen weitgehend denen auf dem Produktivsystem entsprechen. Allein auf Basis von konsistenten und realistischen Daten können Firmen zu Testzwecken praxisnahe Ernstfälle simulieren. Eigenentwicklungen und Modifikationen sollten Anwender ebenfalls mit konsistenten und produktionsnahen Daten testen. Für Prüfungen von Patches und Release-Wechseln eignet sich eine mit dem Produktivsystem möglichst identische Testumgebung. Besonders in Entwicklungs- und Schulungssystemen ist es dabei grundsätzlich wichtig, sensible Daten zu anonymisieren, um die Regeln des Datenschutzes einzuhalten.

Bislang war es üblich, Testsysteme zu einem bestimmten Stichtag als Mandanten- oder Systemkopie des Produktivsystems zu erstellen. In diesen Fällen wird ein einzelner Mandant beziehungsweise das gesamte SAP-System dupliziert. Die entsprechenden Instanzen des SAP-Systems müssen neu installiert werden. Darüber hinaus muss eine Kopie der Quelldatenbank angelegt werden. Dabei handelt es sich um Standardverfahren, die bei produktiven Datenbeständen von mehreren Terabyte allerdings unverhältnismäßig teuer werden können. Mit Hilfe von Tools der SAP und von Drittanbietern zur selektiven Datenextraktion lassen sich die Kosten für die Bereitstellung von nicht produktiven SAP-Systemen deutlich senken.

Das Zielsystem

Grundsätzlich unterscheidet man zwischen Erstaufbau und Refresh eines nicht produktiven SAP-Systems. In der Vergangenheit entsprach der Aufwand für einen Refresh, also die Aktualisierung der Umgebung mit neuen Daten, oft dem Aufwand für den Erstaufbau. Dabei wurde außerdem die Verfügbarkeit des Produktivsystems eingeschränkt, was von Unternehmen, die international und in verschiedenen Zeitzonen agieren, kaum zu tolerieren ist.

Ein nicht produktives SAP-System sollte zudem den gleichen Repository-Stand wie das Quellsystem haben, unabhängig davon, welche Methode zur Datenübertragung beim Refresh gewählt wird. Im Repository sind sämtliche Daten abgelegt, die ein SAP-System ausmachen. Dazu zählen unter anderem die Definitionen für die Datenbankfelder sowie Tabellen für Stamm- und Bewegungsdaten.

Um ein Zielsystem aufzubauen, das zu Test-, Entwicklungs- und Schulungszwecken genutzt werden kann, gibt es zwei unterschiedliche Vorgehensweisen: Anwender können ein SAP-System neu installieren und alle Transporte und Support-Packages einspielen, die bis dato auch in das Produktivsystem gelangt sind. Wenn deren Zahl in die Hunderte und Tausende geht, wird der Aufwand jedoch unverhältnismäßig hoch. Darüber hinaus müssen anschließend auch die Daten noch aus dem Produktivsystem importiert werden, beispielsweise per Mandantenkopie.

Im Normalfall wird deshalb das Zielsystem mit Hilfe einer Kopie des Produktivsystems erstellt. Die Vorteile hierbei sind: Nach dem Erstaufbau sind bereits Daten vorhanden, und die Anwender erhalten eine vollkommen identische Testumgebung. Nachteile dieses Vorgehens sind jedoch der hohe Speicherplatzbedarf, die fehlende Anonymisierung der Daten sowie die lange Laufzeit des Kopiervorgangs.

Die Systemkopie

Eine Systemkopie lässt sich entweder mit SAP-Transaktionen (R3trans, ab R4.6C SAPinst) oder auf Datei- und Datenbankebene erstellen. Kosten und Aufwand wachsen dabei mit der Größe des Systems sowie den Anforderungen an Verfügbarkeit und Datenschutz. Zudem sind oft administrative Nacharbeiten notwendig, angefangen beim Systemnamen bis hin zu Druckern und Schnittstellen.

Um virtualisierte Systeme wie beispielsweise VMware-Instanzen herunterzufahren und zu kopieren, genügen wenige Mausklicks. VMware eignet sich, um mehrere Schulungs-, Entwicklungs- und Testumgebungen auf einem physikalischen System laufen zu lassen. Größere produktive Systeme sind dagegen nicht so einfach zu virtualisieren. Müssen Anwender das Produktivsystem während der Kopie herunterfahren, wird die Laufzeit des Vorgangs beziehungsweise die Nichtverfügbarkeit des produktiven Systems zum kritischen Faktor.

Kritischer Fakor: Verfügbarkeit

International agierende Unternehmen, die Systeme mit mehreren Terabyte Daten und hunderten Benutzern in verschiedenen Zeitzonen betreiben, sind auf hohe Systemverfügbarkeit angewiesen. Zur Not wird das System inkrementell, Tabelle für Tabelle, am Wochenende und nachts kopiert. Das vollständige Herunterfahren des Produktivsystems soll am besten ganz vermieden werden.

Sicherheitsbewusste Unternehmen halten ihre unternehmenskritischen IT-Infrastrukturen in der Regel ohnehin redundant vor. Speichersysteme sind in Disk Arrays meist durch mehrstufiges Raid gesichert, räumlich voneinander getrennt sowie durch ein Storage Area Network (SAN) vernetzt. Daran angeschlossen sind mindestens zwei, ebenfalls räumlich getrennte Rechner. Einer davon fungiert als Backup-System.

Ein SAN ermöglicht eine Systemkopie während des Dialogbetriebs. So lassen sich virtuelle Kopien eines logischen Volumes, so genannte Snapshots, erzeugen. Dabei werden Daten nur kopiert, wenn sie im originalen Datenbestand verändert werden (Copy-on-Write-Verfahren). Wenn von einem Snapshot auf Dateiebene kopiert wird, bleiben die betroffenen Systeme verfügbar. Allerdings belastet diese Vorgehensweise das Speichernetz. Dauert dies mehrere Tage, verschlechtern sich die Antwortzeiten des Produktivsystems.

Vorteil der Systemkopie: Anwender erhalten hundertprozentig konsistente Testdaten. Nachteilig ist jedoch der hohe Speicherplatzbedarf eines solchen Testsystems, der dem des Produktivsystems entspricht. Zudem ist ein Berechtigungskonzept für die Systemkopie erforderlich, um die darin enthaltenen authentischen Daten zu schützen. Andernfalls sind Betriebsgeheimnisse gefährdet, und es liegt ein Verstoß gegen Vorschriften wie das Bundesdatenschutzgesetz und den Sarbanes-Oxley Act vor.

Der Refresh

Veralten die Datenbestände, lassen sie sich durch eine weitere Systemkopie aktualisieren. Aus technischer Sicht entspricht ein solcher Refresh dem Erstaufbau inklusive der damit verbundenen Kosten sowie der Belastung der produktiven Systeme und manueller Nacharbeiten. Darüber hinaus unterbricht ein Refresh auch alle Vorgänge auf dem Zielsystem. Handelt es sich um ein Entwicklungssystem, müssen sämtliche neueren Entwicklungsobjekte gerettet und nach der Kopie wieder hineintransportiert werden. Die Versionshistorie geht dabei verloren.

Als Alternative hierzu bietet sich ein Refresh per Mandantenkopie an. Der Testumgebung fehlen dann zwar unter anderem Audit-Belege, aber die Entwicklungsobjekte bleiben unberührt. Die Mandantenkopie funktioniert nur aus einem laufenden SAP-System heraus, sie belastet dieses aber mit Datenbankabfragen und transferiert Daten langsamer als bei einer Systemkopie. Der betroffene Mandant ist während des Kopiervorgangs nicht verfügbar. Da es innerhalb des Mandanten keine Möglichkeiten gibt, auszuwählen, was alles kopiert werden soll, ist die Laufzeit oft inakzeptabel.

Unternehmen mit Backup-Systemen können diese für eine Mandantenkopie nutzen und somit an der Rechenleistung des Produktivsystems sparen. Die Last des Kopierens fällt dabei jedoch auf das SAN. Weil die Ausfallsicherheit durch die Zweckentfremdung des Backup-Systems eingeschränkt ist und das Speichernetz zusätzlich belastet wird, sollten Anwender die Laufzeit dieser Refresh-Variante möglichst gering halten.

Effizienter aktualisieren

Mittlerweile gibt es eine Reihe von Tools, die Refresh-Aktivitäten von nicht produktiven SAP-Systemen vereinfachen. Die Werkzeuge werden durch Transporte in SAP-Systeme eingespielt und ermöglichen es, die zu kopierenden Daten einzuschreiben. Je genauer die Auswahl, desto größer ist das Einsparpotenzial an Speicherplatz und Extraktionsdauer gegenüber der Mandantenkopie. Wie bei Letzterer bleiben die Konfiguration erhalten und laufende Entwicklungs- und Testvorgänge ungestört.

SAP bietet dafür eine eigene Lösung an: Mit dem Test Data Migration Server (TDMS) können einzelne Tabellen ausgewählt und indirekt, über ein drittes SAP-System, per Remote Function Call (RFC) vom Quell- ins Zielsystem geschrieben werden. Allerdings ist die Auswahl von Business-Objekten im Standard nicht möglich. Die zu kopierenden Tabellen lassen sich lediglich auf Basis des Datums bestimmen. Die inhaltliche Beschränkung gilt ab einem bestimmten Zeitpunkt. Immerhin lässt sich mit dem SAP-Tool die Laufzeit einer Extraktion von Testdaten gegenüber der Systemkopie oder Mandantenkopie verringern.

Tools von Drittanbietern haben teilweise einen anderen Fokus als TDMS. Die Werkzeuge bieten jeweils eine mehr oder minder allgemein verständliche Benutzerführung und sind damit "Out-of-the-box"-Produkte, die keine externe Beratung zu Einführung oder Anwendung erfordern.

Nur bestimmte Daten kopieren

Anwender müssen sich dabei nicht mit einzelnen Tabellen auseinandersetzen, sondern können auf eine Datenbank von Geschäftsentitäten zurückgreifen. Dass heißt, sie wählen keine Tabellen, sondern Business-Objekte wie Mitarbeiter oder Belege aus. Dazu muss in den Werkzeugen jedoch das Beziehungswissen über das komplexe Datenmodell der SAP enthalten sein. Selbst Unternehmen, die das Aufsetzen von Testsystemen als Service anbieten, leisten dies selten für beliebige SAP-Datenbestände. Zusätzlich können Anwender Objekte selbst definieren, um Customizing und Eigenentwicklungen zu berücksichtigen.