BDLS nach System- und Mandantenkopie: logische Systemnamen umsetzen

Was BDLS macht

Ein logisches System bezeichnet in SAP einen Mandanten eines Systems als Kommunikationspartner, etwa für ALE und IDocs. Üblich sind Namen nach dem Muster <SID>CLNT<Mandant>, zum Beispiel PRDCLNT100 für Mandant 100 im Produktivsystem PRD. Angelegt werden logische Systeme in BD54, die Zuordnung zum Mandanten steht in SCC4.

Der Name steckt nicht nur in der Konfiguration, sondern auch in den Anwendungsdaten: Belege speichern zum Beispiel, aus welchem logischen System sie stammen. Die Transaktion BDLS („Logischen Systemnamen umsetzen“) ersetzt einen alten Namen durch einen neuen, und zwar in allen Tabellenfeldern mit den Domänen LOGSYS oder EDI_PARNUM.

Warum BDLS nach jeder Kopie nötig ist

Nach einer Kopie aus der Produktion steht im QS-System überall PRDCLNT100, obwohl der Mandant dort QASCLNT100 heißt. Ohne Umsetzung verweisen Belege, IDocs und Verteilungseinstellungen weiter auf die Produktion. Verteilung, IDoc-Verarbeitung und Auswertungen, die den Systemnamen nutzen, arbeiten dann mit falschen Angaben.

Nach einer Mandantenkopie reicht es, die mandantenabhängigen Tabellen umzusetzen. Nach einer Systemkopie kommen die mandantenunabhängigen Tabellen hinzu, und zwar für jeden Mandanten, der weiter genutzt wird. In Produktivsystemen ist BDLS nicht vorgesehen.

BDLS Schritt für Schritt

1. Namen festlegen. Alter Name ist der logische Systemname der Quelle, neuer Name der des Zielmandanten, nach der üblichen Konvention zum Beispiel PRDCLNT100 und QASCLNT100.
2. System ruhigstellen. IDocs abarbeiten, Hintergrundjobs anhalten, Benutzer sperren. Während der Umsetzung sollen im System keine anderen Aktivitäten laufen.
3. Testlauf. BDLS mit der Option Testlauf starten. Er ermittelt die betroffenen Tabellen und die Zahl der Einträge und warnt, wenn der neue Name in den Anwendungstabellen schon vorkommt.
4. Umfang und Commit-Größe wählen. Nach einer Mandantenkopie genügen die mandantenabhängigen Tabellen, nach einer Systemkopie kommen die mandantenunabhängigen dazu. Die Zahl der Einträge pro Commit so hoch wählen, wie der Rollback-Bereich der Datenbank erlaubt.
5. Umsetzung im Hintergrund. Den echten Lauf als Hintergrundjob starten. Das Protokoll zeigt danach, welche Tabellen und Felder umgesetzt wurden.
6. Kommunikation prüfen. Zuordnung des logischen Systems in SCC4, Partnervereinbarungen (WE20), Verteilungsmodell (BD64) und RFC-Destinationen kontrollieren.

BDLS schreibt tabellenweise fest. Bricht ein Lauf ab, lässt er sich wieder aufsetzen, ohne von vorn zu beginnen. Welche weiteren Nacharbeiten nach einer Kopie anfallen, zeigt die Checkliste im Artikel SAP-Mandantenkopie.

Warum BDLS so lange dauert

BDLS durchsucht jede Tabelle, die ein Feld mit einer der beiden Domänen enthält. Diese Felder sind meist nicht indiziert. Die Datenbank liest große Tabellen deshalb vollständig, im Testlauf und noch einmal bei der Umsetzung.

Die Laufzeit wächst damit direkt mit dem Datenvolumen. Jede Vollkopie bringt die komplette Historie mit, und BDLS muss sie komplett durchsuchen. Bei großen Systemen sind mehrere Stunden normal, aus der Praxis werden auch mehrtägige Läufe berichtet. Diese Zeit fehlt im Downtime-Fenster.

BDLS beschleunigen

• Commit-Größe erhöhen: Voreingestellt sind 1.000.000 Einträge pro Commit bei Oracle und 100.000 bei anderen Datenbanken. Höhere Werte sparen Zeit, solange der Rollback-Bereich reicht.
• Leere Tabellen ausschließen: Tabellen, deren Felder für logische Systeme nicht gefüllt sind, lassen sich ausschließen, über das Selektionsbild oder die Tabelle BDLSEXZ (SAP-Hinweis 932032). Die Tabelle T000 wird immer umgesetzt.
• Parallel laufen lassen: Mehrere Läufe für unterschiedliche Tabellenbereiche verkürzen die Gesamtzeit, etwa mit dem Report RBDLS2LS (SAP-Hinweis 1547980). Dafür genug Hintergrundprozesse einplanen.
• Große Tabellen gesondert behandeln: Für sehr große Tabellen beschreibt SAP-Hinweis 932032 eine eigene Umsetzungsroutine.
• Weniger Daten kopieren: Was nicht in der Kopie landet, muss BDLS nicht durchsuchen.

Ohne nachträglichen BDLS-Lauf

BDLS ist nötig, weil die Daten zuerst in die Datenbank geschrieben und danach korrigiert werden. Der Data Refresh Operator dreht die Reihenfolge um. Er exportiert die Daten in Dateien und weiß vorab, in welchen Feldern logische Systemnamen stehen. Beim Import ersetzt DRO den alten Namen durch den neuen, bevor die Daten in die Datenbank geschrieben werden. Ein nachträglicher BDLS-Lauf entfällt.

Dazu kommt die Zeitscheibe: DRO kopiert nur den Zeitraum, der für Tests gebraucht wird, plus alle abhängigen Objekte. Das verkürzt den Refresh insgesamt.

3–5×

schneller als eine Vollkopie, in der Praxis

0

BDLS-Läufe nach dem Import

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

Für Systemkopien bleibt BDLS das Mittel der Wahl. DRO ersetzt die Mandantenkopie, nicht die Systemkopie. Wann welches Verfahren passt, zeigt der Vergleich von Mandantenkopie, Systemkopie und Zeitscheibe. Wie der ganze Refresh einschließlich der Nacharbeiten automatisch läuft, zeigt das Beispiel-Playbook.

Quellen

• SAP-Hilfe: Umsetzung logischer Systeme (SAP NetWeaver 7.0 EHP3)
• SAP-Hinweis 932032: BDLS: Special conversion for large tables (SAP-Support-Portal, Anmeldung nötig)
• SAP-Hinweis 1547980: BDLS: Performance (SAP-Support-Portal, Anmeldung nötig)
• SAP Community: Execute conversion of logical system names (BDLS) in short time and in parallel
• Basis Technologies: 5 Dinge, die Kunden an unseren SnapOps-Tools lieben (Praxisbericht zu BDLS-Laufzeiten)