SAP-Systemkopie und System-Refresh: BDLS-Konvertierung und RFC-Ausgangsisolierung prüfen

Das Risiko einer Systemkopie aus der Produktion

Wird ein Qualitätssicherungs- (QS) oder Sandbox-System durch eine Datenbankkopie des Produktivsystems aktualisiert, enthält das Zielsystem zunächst die produktive Konfiguration: produktive RFC-Destinationen, Partnervereinbarungen, Mailserver, Druckerkonfigurationen, eingeplante Hintergrundjobs und logische Systemnamen.

Wird die ausgehende Kommunikation nicht isoliert, bevor die Hintergrundverarbeitung startet, kann das aktualisierte QS-System versehentlich Testbestellungen, IDocs oder Zahlungsträger an reale Geschäftspartner oder produktive Nachbarsysteme senden.

Zentrale Prüfschritte nach dem System-Refresh

1. Umsetzung logischer Systemnamen (BDLS). Konvertieren Sie Verweise vom produktiven logischen Systemnamen auf den logischen Namen des QS-Systems in allen relevanten Tabellen.
2. Isolierung von RFC-Destinationen und Partnerprofilen (SM59, WE20, WE21). Stellen Sie sicher, dass keine RFC-Destination und kein Port im QS-System weiterhin auf einen Produktivhost zeigt.
3. Umleitung von Mail- und Druckausgabe (SCOT, SPAD). Begrenzen oder leiten Sie ausgehende SMTP-Knoten, HTTP-Verbindungen und physische Drucker um, damit keine Testnachrichten an echte Kunden oder Lieferanten gehen.
4. Prüfung von Hintergrundjobs und Queues (SM37, SMQ1, SMQ2). Halten Sie übernommene Produktivjobs angehalten, bis die Delta-Konfiguration eingespielt ist, und bereinigen Sie übernommene qRFC-/tRFC-Queues.

Automatischer Vorher-Nachher-Abgleich

Vergleichen Sie den vor der Kopie gesicherten QS-Sollzustand (RFC-Destinationen, logische Systeme, Partnerprofile, SCOT-Einstellungen) mit dem Zustand nach dem Refresh, bevor das System für Benutzer und Jobs freigegeben wird.

Der System Refresh Delta Guard von ERP Preflight gleicht Vorher- und Nachher-Exporte deterministisch ab und meldet verbliebene Produktivverbindungen sowie nicht umgesetzte logische Systeme mit Nachweis. Siehe Betrieb.