SAP Software Update Manager (SUM) 2.0: Architektur, DMO und die Evolution (Stand 2022)

Willkommen, Tech-Community und SAP-Basis-Kollegen! Wer in der SAP-Welt große System-Conversions, Release-Upgrades oder Datenbank-Migrationen durchführt, kommt an einem Tool nicht vorbei: dem Software Update Manager (SUM). In diesem extrem detaillierten Deep-Dive analysieren wir die historische und aktuelle technische Evolution des SUM mit einem harten Fokus auf die Architektur und Best Practices des Jahres 2022. Wir verknüpfen dabei klassisches Basiswissen nahtlos mit den entscheidenden Upgrade-Mechanismen der SAP S/4HANA-Ära, die in den aktuellen Upgrade-Guides und Checklisten referenziert werden.

Die historische Evolution: Von SAPup zum SUM 2.0

Um die aktuelle Architektur des SUM zu verstehen, müssen wir einen kurzen Blick auf seine Historie werfen. In den frühen Tagen der SAP R/3- und NetWeaver-Ära wurden Updates und Upgrades strikt getrennt behandelt. Für Support Packages nutzte man die Transaktionen SPAM und SAINT. Für Major-Release-Upgrades kamen Standalone-C-Programme wie SAPup (für den ABAP-Stack) und SAPJup (für den Java-Stack) zum Einsatz.

Mit der zunehmenden Komplexität von Dual-Stack-Systemen und der Einführung von SAP HANA bündelte SAP diese C-Routinen in ein einheitliches Framework: den Software Update Manager (SUM 1.0).

Mit dem Aufstieg von SAP S/4HANA spaltete SAP die Tool-Linie auf: Der SUM 2.0 wurde geboren. Der SUM 2.0 ist zwingend erforderlich für alle ABAP-Systeme, die auf SAP NetWeaver 7.5 oder höher basieren, und ist das exklusive Werkzeug für S/4HANA System Conversions. Aktuell wird der SUM 2.0 durch zahlreiche Support Packages (wie das neueste SUM 2.0 SP13) immer weiter auf Downtime-Optimierung und Cloud-Bereitschaft getrimmt.

Architektur und Kernkomponenten des SUM 2.0

Der SUM ist kein simples Skript, sondern ein hochkomplexer Orchestrator, der Tausende von Einzelschritten (Phases) kontrolliert.

Die Ausführung beginnt mit dem Entpacken des SUM-Archivs (via SAPCAR) in das Verzeichnis /usr/sap/<SID>/SUM (wie auch in den UNIX-spezifischen S/4HANA-Guides beschrieben). Die technische Kontrolle liegt bei dem Prozess SAPup, der heute elegant über den SUM ABAP Observer gesteuert wird – in der Regel über den modernen, Browser-basierten SL Toolset UI5-Client.

Die Konfiguration wird maßgeblich durch die Stack.xml gesteuert. Diese Datei wird vorab im Maintenance Planner in der SAP Support Cloud generiert, enthält die exakte Stückliste (BOM - Bill of Materials) aller benötigten SAR-Archive und definiert den Ziel-Release-Stand (z. B. den Sprung auf das aktuelle S/4HANA 2021 oder Vorbereitungen auf das kommende Release 2022).

Die SUM Phasen im technischen Detail

Ein In-Depth-Upgrade mit dem SUM 2.0 ist in sechs Hauptphasen unterteilt. Keine dieser Phasen darf in der Planung unterschätzt werden:

1. Extraction (EXTRACTION): Der SUM liest die Stack.xml, entpackt die Archive und initialisiert die Upgrade-Verzeichnisse. Hier wird auch das fundamentale SUM-Dictionary aufgebaut. Wichtige Logs: STARTUP.LOG, SAPup.log.

2. Configuration (CONFIGURATION): Die interaktive Phase. Der Basis-Administrator legt hier Parameter fest, wie beispielsweise die Anzahl der Batch-Prozesse (R3trans, R3load) und die Downtime-Strategie. Die Target-Datenbank wird hier ebenfalls angebunden.

3. Checks (CHECKS): Hier passieren die essenziellen Vorabprüfungen. Der SUM prüft freie Tabellenspaces und OS-Limits. Absolut kritisch für S/4HANA-Upgrades (etwa von Release 1909 auf 2021) sind die Simplification Item Checks (SI-Checks). Zeigt der Report /SDF/RC_START_CHECK rote Ampeln, erzwingt der SUM einen Hard-Stop. Wichtige Logs: CHECKS.TXT.

4. Preprocessing (PREP): Das ist die technische Meisterleistung des SUM. Während das Produktivsystem (Uptime) voll weiterläuft, baut der SUM ein Schattensystem (Shadow System) auf. Eine zweite Instanz wird parallel hochgefahren (mit eigenem Shadow-Repository). DDIC-Aktivitäten (Data Dictionary) wie das Anlegen neuer Tabellen und Indexe passieren komplett im Schatten. Gegen Ende dieser Phase werden die Entwicklerumgebungen gesperrt (Lock Development). Wichtige Logs: SHADOW_IMPORT_INC.LOG.

5. Execution (EXECUTION - The Downtime): Die Stunde der Wahrheit: DOWNTIME_STARTS_HERE. Das Produktivsystem wird gestoppt. Das Schattensystem übernimmt die Führung. Der Switch-Framework wird aktiviert, Tabellen werden per R3load oder R3trans in den neuen Namensraum konvertiert. Bei Migrationen findet hier die massive Datenübertragung statt. Die Ausfallzeit hängt massiv von der I/O-Performance der Hardware und der Verteilung der R3load-Prozesse ab.

6. Postprocessing (POSTP): Nach dem Start des neuen Systems auf dem Ziel-Release führt der SUM Bereinigungen durch. Das Schattensystem wird gelöscht. Entwickler müssen nun zwingend die Transaktionen SPDD und SPAU abarbeiten, um SAP-Standard-Modifikationen mit dem neuen Release abzugleichen.

Die Revolution: DMO (Database Migration Option) & DMOVE2S4

Eine der größten Innovationen in der SUM-Architektur ist die Database Migration Option (DMO). Historisch (vor 2013/2014) musste eine Migration auf SAP HANA in zwei Schritten erfolgen: Erst das Upgrade (via SUM), dann die Datenbankmigration (via SWPM - Software Provisioning Manager).

Die DMO verheiratet beide Prozesse: Der SUM 2.0 führt das Release-Upgrade und die Migration der AnyDB (Oracle, DB2, MS SQL) auf die SAP HANA-Datenbank in einem einzigen Durchlauf aus.

Ein besonders spannendes, aktuelles Architektur-Feature ist die Homogeneous Option for DMO und das Szenario DMOVE2S4. Während die klassische DMO primär für heterogene Migrationen gedacht war, ermöglicht SAP damit homogene Migrationen (HANA zu HANA) – unerlässlich beim Wechsel des Rechenzentrums, dem Umzug zu Hyperscalern oder für S/4HANA Downtime-Optimierungen. Der SUM nutzt hier hochentwickelte R3load-Pipes, um Daten speicheroptimiert von der Quelle direkt ins Ziel zu pumpen, ohne sie auf Festplatten zwischenspeichern zu müssen.

Aktuelle Downtime-Optimierungsstrategien (Stand 2022)

Da bei großen ERP-Systemen jede Minute Downtime bares Geld kostet, stattet SAP den SUM mit massiven Optimierungstechniken aus:

• Near-Zero Downtime Maintenance (nZDM): Durch einen "Record & Playback"-Mechanismus (CRR - Customer Relationship Repository) werden Datenänderungen (Inserts, Updates), die Nutzer während der Uptime machen, aufgezeichnet. Diese werden direkt in das Schattensystem repliziert. Das verringert die notwendige Datenübernahme in der Execution-Phase drastisch.

• Zero Downtime Option (ZDO): Die Königsklasse des SUM. Aktuell wird die ZDO massiv ausgebaut. Hierbei arbeiten die Endanwender auf einer Art Klon der Datenbankarchitektur weiter, während das Upgrade im Hintergrund abgeschlossen wird. Die finale "Downtime" reduziert sich auf den bloßen Applikationsneustart.

S/4HANA Upgrades: Die Checkliste für Conversions

Ein System-Upgrade auf SAP S/4HANA (z.B. der Pfad von Release 1909 auf 2021) erfordert laut den aktuellen Checklisten und Upgrade-Guides akribische Vorbereitung. Die absolute technische Baseline umfasst:

1. CVI (Customer Vendor Integration): Die Business Partner Conversion muss auf dem ERP-System zwingend abgeschlossen sein, bevor der SUM im S/4HANA-Kontext überhaupt starten darf.

2. Bereinigung des SI-Katalogs: Wie im CHECKS-Kapitel erwähnt, sind ungelöste Simplification Items der häufigste Grund für Abbrüche in der PREP-Phase.

3. Spool- und Job-Cleanup: Reduzierung von großen TST03-Tabellen und obsoleten Background-Jobs, um die R3load-Zeiten während der Execution-Phase drastisch zu minimieren.

Aktuell, Anfang 2022, steht die SAP-Basis-Welt durch die neuesten SUM-Releases an der Schwelle zu noch tieferer Cloud-Integration, was den Weg für künftige Upgrades auf S/4HANA 2022 und Folgeversionen ebnet.

Fazit

Der Software Update Manager (SUM 2.0) ist heute, im Jahr 2022, zu einem hochgradig resilienten, cloud-fähigen und massiv parallelisierten Orchestrierungstool herangewachsen. Was einst mit simplen SAPup-C-Routinen begann, ist heute eine Meisterleistungs-Architektur, die Datenbankmigration (DMO), Release-Upgrades und komplexe S/4HANA Conversions in einem einzigen Run bündelt.

Für jeden ambitionierten SAP Technology Consultant gilt: Das exakte Beherrschen der sechs SUM-Phasen, das tiefe technische Verständnis des Schattensystems und die strategische Nutzung von Features wie der Homogeneous Option und nZDM sind der Garant für eine erfolgreiche S/4HANA-Transformation. Wer die Mechanik hinter R3load-Pipes versteht und Log-Dateien fehlerfrei interpretieren kann, steuert das SAP-System sicher durch jede anstehende technische Evolution.