SAP System Refresh: Runbook für den QS-Refresh

SAP System Refresh: worum es geht

Bei einem Refresh wird ein bestehendes Zielsystem mit aktuellen Daten aus einem Quellsystem überschrieben, meist QS aus der Produktion. Anders als beim Aufbau eines neuen Systems soll das Ziel dabei seine Konfiguration behalten. System-ID, Verbindungen, Benutzer, Transportwege und Drucker bleiben die des QS-Systems.

Technisch gibt es zwei Wege. Die SAP-Systemkopie ersetzt die ganze Datenbank, einschließlich Repository und aller Mandanten. Die Mandantenkopie ersetzt nur einen Mandanten. Welche Varianten es dafür gibt, zeigt der Grundlagenartikel im Abschnitt Lokal, remote oder per Export. Der organisatorische Rahmen ist bei beiden gleich und folgt sieben Phasen:

Planung und Abstimmung. Termin, Downtime-Fenster, betroffene Tests und Transporte klären, Refresh ankündigen.
Ramp-down. Das QS-System ruhigstellen: Benutzer sperren, Jobs und Schnittstellen anhalten.
Sicherungen. Alles sichern, was das System als QS ausmacht: Benutzer, Transportpuffer, Verbindungen, Einstellungen.
Kopie. Datenbank oder Mandant aus der Produktion übertragen.
Nacharbeiten. Das System von der Produktion trennen und die QS-Einstellungen wiederherstellen.
Ramp-up. Prüfen, Schnittstellen und Jobs einschalten, Benutzer entsperren.
Freigabe und Dokumentation. Abnahme durch die Fachbereiche, Laufzeiten und Abweichungen festhalten.

Vom Ramp-down bis zum Ramp-up steht das QS-System den Testern nicht zur Verfügung. Je kürzer Kopie und Nacharbeiten, desto kürzer das Downtime-Fenster.

Phase 1: Planung und Abstimmung

Ein Refresh nimmt den Fachbereichen ihr Testsystem für Stunden oder Tage. Laufende Tests verlieren ihren Datenstand. Stimmen Sie den Termin deshalb früh ab und klären Sie diese Punkte:

Fachbereiche und Projekte: Welche Tests laufen gerade, welche Testdaten müssen danach wieder angelegt werden, wer testet nach der Freigabe?
Entwicklungsstand: Transportaufträge ermitteln, die in QS importiert, aber noch nicht produktiv sind. Nach einer Systemkopie fehlen sie im Repository, nach einer Mandantenkopie fehlt ihr mandantenabhängiges Customizing. Beides muss danach erneut importiert werden.
Downtime-Fenster: Die Dauer aus dem letzten Refresh oder einem Testlauf ableiten, wie SAP ihn für Systemkopien empfiehlt, und einen Puffer für die Nacharbeiten einplanen. Kopien mit Produktionsdaten mit Monats- und Jahresabschlüssen abstimmen.
Angebundene Systeme: Klären, welche Test- und Partnersysteme am QS-System hängen und wer sie während des Refreshs anhält und danach wieder anbindet.
Kommunikation: Termin, Dauer und Ansprechpartner per E-Mail ankündigen. Kurz vor dem Start eine Systemnachricht in SM02 anlegen.

Phase 2 und 3: Ramp-down und Sicherungen

Zu Beginn des Downtime-Fensters wird das QS-System ruhiggestellt. Angemeldete Benutzer werden informiert und abgemeldet, Dialogbenutzer mit SU10 gesperrt, ausgenommen das Basis-Team. Laufende Jobs prüfen Sie in SM37. Schnittstellen zu Partnersystemen werden unterbrochen, etwa die Verarbeitung von IDocs und die qRFC- und tRFC-Warteschlangen.

Die Produktion läuft bei einem Refresh weiter. Ihre Jobs kommen aber mit der Kopie ins QS-System und dürfen dort nicht anlaufen. Verbreitet ist, das Zielsystem nach der Kopie zunächst ohne Hintergrundprozesse zu starten (Profilparameter rdisp/wp_no_btc auf 0) und die Jobs dort mit dem Report BTCTRNS1 auszusetzen. Offene Verbuchungen in SM13 sollten in der Quelle zum Zeitpunkt der Sicherung möglichst abgearbeitet sein.

Bevor das QS-System überschrieben wird, sichern Sie alles, was es als QS ausmacht. SAP beschreibt das Prinzip in der ABAP Post-Copy Automation, einem Teil von SAP Landscape Management: Die Aufgabenliste SAP_BASIS_COPY_REFRESH_EXPORT exportiert vor der Kopie Konfigurationstabellen des Zielsystems per R3trans ins Dateisystem. Nach der Kopie werden Tabellen mit Daten der Quelle bereinigt und die Konfiguration wieder importiert. Welche Tabellen exportiert werden, zeigt der Report SCTC_LIST_TABLES. Ob mit oder ohne Aufgabenliste, diese Sicherungen gehören dazu:

Benutzer und Berechtigungen: zum Beispiel per Mandantenexport mit dem Kopierprofil SAP_USER (SCC8).
Transportwesen: Den Importpuffer des QS-Systems im Transportverzeichnis sichern und die Liste der erneut zu importierenden Aufträge ablegen.
Systemspezifische Einstellungen: Logische Systemnamen (SCC4), RFC-Destinationen (SM59), Partnervereinbarungen (WE20), Drucker (SPAD), Lizenzschlüssel (SLICENSE), Zertifikate (STRUST) und Anmeldegruppen (SMLG) exportieren oder dokumentieren.
Rückfallebene: Eine Datensicherung des QS-Systems, falls der Refresh abgebrochen werden muss.

Phase 4 und 5: Kopie und Nacharbeiten

Für einen Refresh per Systemkopie stellen Sie eine Sicherung der Produktion im QS-System wieder her. Bei SAP HANA ersetzt die SWPM-Option „Refresh Database Content“ nur den Datenbankinhalt eines bestehenden Systems, die Instanzen werden nicht neu installiert. Die Anwendungsserver des Ziels werden dafür gestoppt, die ASCS-Instanz läuft weiter. Methoden und Ablauf beschreibt der Artikel SAP-Systemkopie.

Für einen Refresh per Mandantenkopie kopieren Sie den Produktivmandanten remote mit SCC9 bzw. SCC9N. Repository und Entwicklungsstand bleiben dabei erhalten. Den Mandantentransport mit SCC8 und SCC7 sieht SAP laut Leitfaden zur Systemkopie nicht für Produktivmandanten vor, sondern für den Erstaufbau einer Systemlandschaft.

Danach folgen die Nacharbeiten. Zuerst kommt alles, was das System von der Produktion trennt, danach die Wiederherstellung der QS-Einstellungen:

Trennen. Das System zunächst nur für das Basis-Team öffnen. RFC-Destinationen und Warteschlangen prüfen, Ausgabe über Drucker, E-Mail und EDI sperren.
Lizenz und Transportwesen. Den QS-Lizenzschlüssel einspielen. Nach einer Systemkopie in SE06 die Nachbearbeitung für eine Datenbankkopie ausführen und das Transportwesen in STMS wieder einrichten.
Logische Systeme. Die Namen mit BDLS vom Namen der Produktion auf den des QS-Mandanten umsetzen. Warum das dauert, erklärt der Artikel BDLS nach System- und Mandantenkopie.
QS-Einstellungen zurückspielen. Gesicherte Benutzer, RFC-Destinationen, Partnervereinbarungen, Drucker und Zertifikate wiederherstellen.
Jobs. Jobs der Produktion löschen oder anpassen und nur die im QS benötigten Jobs freigeben, nach einer Systemkopie mit BTCTRNS2.
Transporte. Die in Phase 1 ermittelten Transportaufträge erneut importieren.
Daten schützen. Personenbezogene Daten maskieren, bevor Tester und Entwickler zugreifen.

Die vollständigen Listen finden Sie in der Checkliste für die Nacharbeiten nach einer Mandantenkopie und in den Nacharbeiten nach der Systemkopie.

Phase 6 und 7: Ramp-up, Freigabe und Dokumentation

Erst wenn das System getrennt und eingerichtet ist, geht es zurück an die Nutzer:

Prüfen: Konsistenzprüfung (SM28) und Systemlog (SM21), Anmeldung mit Testbenutzern, Stichproben in den wichtigsten Prozessen.
Ramp-up: Schnittstellen zu den Testpartnern einschalten, Jobs einplanen, Benutzer mit SU10 entsperren, Systemnachricht entfernen.
Freigabe: Die Fachbereiche bestätigen, dass Daten und Funktionen für ihre Tests passen. Erst dann ist der Refresh abgeschlossen.
Dokumentation: Laufzeiten jeder Phase, Abweichungen und offene Punkte festhalten und das Runbook für den nächsten Refresh aktualisieren.

Checkliste für den QS-Refresh

Die Phasen in Kurzform zum Abhaken:

Termin mit Fachbereichen und Projekten abgestimmt, Downtime-Fenster festgelegt
Transporte ermittelt, die in QS, aber noch nicht in der Produktion sind
Refresh per E-Mail und Systemnachricht angekündigt
Benutzer gesperrt, Jobs und Schnittstellen angehalten
Benutzer, Transportpuffer und QS-Einstellungen gesichert
Sicherung des QS-Systems als Rückfallebene vorhanden
Kopie abgeschlossen, Protokolle geprüft
RFC-Verbindungen, Ausgabe und Jobs von der Produktion getrennt
Lizenz, Transportwesen und logische Systemnamen angepasst
Benutzer und QS-Einstellungen zurückgespielt
Offene Transporte erneut importiert
Personenbezogene Daten maskiert
Prüfungen erfolgreich, Fachbereiche haben freigegeben
Laufzeiten, Abweichungen und offene Punkte dokumentiert

Den SAP-Refresh als Playbook automatisieren

Das Runbook ist jedes Mal gleich. Trotzdem arbeiten es viele Teams von Hand ab, oft am Wochenende und mit dem Risiko, einen Schritt zu vergessen.

Läuft Ihr QS-Refresh als Mandantenkopie, kann der Data Refresh Operator diesen Ablauf übernehmen. DRO-Playbooks automatisieren die Ankündigung, warten auf das Downtime-Fenster und führen den Ramp-down aus: Jobs anhalten, Benutzer sperren, Schnittstellen unterbrechen, Nummernkreisstände sichern. Es folgen das Backup der Benutzerstämme, der Import, kundenspezifische Nacharbeiten und der Ramp-up. Logische Systemnamen ersetzt DRO schon beim Import, bevor die Daten in die Datenbank geschrieben werden. Ein nachträglicher BDLS-Lauf entfällt.

Kopiert wird eine Zeitscheibe, zum Beispiel die letzten 90 Tage, plus alle abhängigen Objekte aus älteren Jahren. Bricht ein Lauf ab, setzt DRO auf Ebene atomarer Arbeitspakete wieder auf, und jeder Schritt landet im Audit-Trail.

3–5×: schneller als eine Vollkopie, in der Praxis
0: BDLS-Läufe nach dem Import

Praxiswert, keine Garantie. Je nach System, Zeitraum und Ausnahmelisten kann der Vorteil auch deutlich größer sein. DRO läuft ab SAP S/4HANA 2023.

DRO ersetzt die Mandantenkopie, nicht die Systemkopie. Für einen Refresh per Systemkopie bleiben SWPM und die Nacharbeiten oben das Werkzeug. Wie ein automatisierter Refresh von Freitagabend bis zur Übergabe aussieht, zeigt das Beispiel-Playbook.

SAP System Refresh: QS-Refresh als Runbook vom Ramp-down bis zur Freigabe