Dewegen habe ich es mir zum Ziel gemacht, in nächster Zeit immer mal wieder Übersetzungen für SAP-Begrifflichkeiten in Deutsch und Englisch bei dict.cc einzureichen. Diese tauchen jedoch nur dann in der öffentlichen Trefferliste auf, wenn es genügend Votes gibt, die meine Vorschläge bestätigen. Damit wir endlich eine schnelle Plattform zur Übersetzung von SAP-Termina in Deutsch und Englisch erhalten, würde ich diese Übersetzungen mit eurer Hilfe gerne aufbauen.

Erstellt euch hierzu auf dict.cc einen Account und votet für meine Übersetzungsvorschläge. Ich würde gerne mehrere Übersetzungsvorschläge einreichen, kann dies jedoch erst tun, wenn ich auf meine bisherigen Vorschläge erste Votes bekommen habe. Je schneller ihr votet, desto eher kann ich neue Übersetzungsvorschläge einreichen.

Es wird demnächst wieder mehr zu lesen und hören geben.

Viele Grüße

DaFRK

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

https://www.andreas-loibl.eu

Der Beitrag Unterstützt mich bei der Übersetzung von SAP Begriffen erschien zuerst auf DaFRK - Online Brainware for IT Professionals.

Sie finden in diesem Beitrag eine Sammlung von Tipps. Viele davon stammen aus offiziellen SAP Blogs und aus SAP Hinweisen, die ich entsprechend als Quelle verlinke. Dadurch ist quasi ein Nachweis der „Legitimität“ dieser Optimierungsmaßnahmen gegeben, so dass Sie hier keine Experimente eingehen und Ihr Upgrade eher verschlimmbessern.

Approach-übergreifende Performance Maßnahmen

Die hier gelisteten Maßnahmen sind gültig, völlig unabhängig davon, ob Sie ein Upgrade, eine Systemkopie, eine DMO oder eine System Conversion vor haben. Sie helfen Ihnen in allen Lebenslagen und sollten daher in jedem Upgrade- und Migrations-Projekt angewandt werden.

sauberes Sizing von Quell- und Zielsystem

Erster Schritt für gute Performance in SAP Upgrade- und Migrations-Projekten ist ein sauberes Sizing der Systeme, auf denen die zu wartenden Systeme installiert werden bzw. wohin sie migriert werden. Ich habe sowohl grundsätzlich über den SAP Quick Sizer als auch über das Sizing unter SAP HANA bereits entsprechende Beiträge veröffentlicht. Außerdem, wenn Sie zusammen mit beispielsweise einer DMO eine Unicode Conversion durchführen, habe ich Ihnen hier aufgezeigt, welche zusätzlichen Ressourcen Sie nach einer Unicode Conversion einkalkulieren sollten.

Zusätzlich liefert die SAP hin und wieder Hinweise für bestimmte Zielreleases aus, welche aufzeigen, welchen Zuwachs an Ressourcen ein bestimmter Release bei SAP Kunden verursacht hat. Für SAP ERP 6.0 EHP 7 und 8 ist das beispielsweise die Note 1974405 – Resource requirements for SAP ERP Central Component 6.0 EHP7 and EHP8.

Für ein SAP S/4HANA Zielrelease gibt es eine solche Note derzeit noch nicht. Die Message, die sich dahinter verbirgt: Wenn ein SAP ERP Anwendungsserver bei dir läuft, läuft auch ein S/4HANA Anwendungsserver bei dir (meine Worte, nicht die offiziellen der SAP).

Datenvermeidung und Datenbereinigung

Der folgende Abschnitt schildert Maßnahmen zur Vermeidung und Berienigung von Daten. Klar ist: Je kleiner das System, desto kürzer das Upgrade bzw. die Migration. Deswegen sind diese Strategien ein wesentlicher Bestandteil der Optimierung.

Unter Oracle als Quelldatenbank gibt es den Hinweis 2388483 – How-To: Data Management for Technical Tables , der sich auch mit der Vermeidung von Datenwachstum in Basis-Tabellen beschäftigt.

Wenn Sie den CRM Marketing Segment Builder nutzen, können Sie zur Reduzierung der Downtime Zielgruppen aus dem System löschen. Daraufhin baut bei einem Upgrade oberhalb von NW 7.40 SP08 einen Sekundärindex auf die dadurch betroffene Tabelle CRMD_MKTTG_TG_I Tabelle während des Upgrades neu auf. Dieser Neuaufbau dauert natürlich seine Zeit. Dieser Schritt ist notwendig und kann daher nicht übersprungen werden. Als Daumenregel benötigt der Wiederaufbau dieses Index für 10 Millionen Einträge etwa 200 Sekunden Zeit. auf moderner Hardware. Je mehr Target Groups Sie also im Vornherein löschen können, desto niedriger die Downtime an dieser Stelle.

Housekeeping ist im SAP BW System nochmal ein ganz eigenes Thema. Zunächst sollten Sie prüfen, ob SAP Note 2026343 auf Sie zutrifft.

Transaktion DB02 – fehlende Tabellen und Indizes

Sie sollten auf jeden Fall in der DB02 den Punkt „fehlende Tabellen und Indizes“ nachziehen. Nicht nur verbessern die Indizes die Selektion der Daten, dieser Punkt verhindert auch eventuelle Abbrüche in der Vorbereitungsphase des Software Update Manager

Nutzen Sie einen aktuellen Kernel und die SPAM im Quell- und Zielrelease

Damit ist gemeint, dass Sie auf dem Quellrelease (z. B. SAP Netweaver 7.31) einen möglichst aktuellen Kernel mit hohem Patchlevel verwenden sollen. Insbesondere sind hierbei wichtig die folgenden Komponenten des Kernels

• dbsl (Database shared Library)
• tp
• die sogenannten R3*Tools (R3load, R3trans, usw.)
• Die BR*Tools (hauptsächlich, weil veraltete BR*Tools nicht mit neueren R3*Tools kompatibel sind)

Für das Zielrelease sollten Sie bei der Planung der Wartung mit dem Maintenance Planner einen möglichst aktuellen Kernel zum Download auswählen. Im Zweifel können Sie sogar während der SUM-Prozedur die dbslib und die R3*Tools noch austauschen. Bei einer Database Migration Option etwa, bei welcher Sie von einem NetWeaver 7.31 auf einer Oracle Datenbank auf ein NetWeaver 7.51 on HANA wollen, erzeugt der SUM einmal einen NetWeaver 7.45 Kernel für Oracle und einmal einen NetWeaver 7.45 Kernel für die HANA. Sie haben also zwei Kernel im Zielrelease. Ein Kernel ist für den Export von Daten aus der Oracle zuständig, der andere für den Import der Daten in die HANA. Sie können die R3*Tools beider Kernel im SUM-Verzeichnis bei der entsprechenden Phase austauschen, oder im Vornherein die aktuellen Versionen von tp, den R3*Tools und der dbsl über SAPCARin das SAR Archiv der Kernel integrieren. Aber ist das wirklich empfohlen? Der Maintenance Planner hat sich schließlich etwas dabei gedacht, als er Ihnen die entsprechenden Kernel zum Download untergeschoben hat. Und können Versionen der R3*Tools, die sehr frisch und daher kaum getestet sind, nicht zu Fehlern führen? Der grundsätzliche Menschenverstand sagt dazu ja. Die SAP empfiehlt in SAP Note aber 1616401 explizit, immer die „latest version“ von tp und R3trans zu nutzen. Da es wiederum keinen Sinn macht, R3trans getrennt von den restlichen R3*Tools zu aktualisieren, gilt für mich die Empfehlung, die R3*Tools komplett zu aktualisieren. Meiner Praxiserfahrung nach hatte ich bisher noch keine Probleme, wenn ich die Kernel Executables aktualisiert habe – aber immer Probleme, wenn ich es nicht gemacht habe.

Prüfen Sie bei der Aktualisierung, ob die einzelnen R3*Tools im Einzeldownload oder im Bundle innerhalb des EXE/EXEDB-Pakets neuer sind. Meistens sind die R3*Tools, die einzeln zum Download angeboten werden, neuer – es kam jedoch auch schonmal vor, dass die Version im EXE/EXEDB-Paket ein neueres Patch Level hat als der Einzeldownload. Dies ist in der Regel bei runden Patchlevels der Fall.

In der Vergangenheit gab es schon öfters Gegebenheiten, bei welcher eine neuere Version dieser Kernel-Komponenten die Geschwindigkeit von SUM-Prozeduren erheblich steigern konnte. SAP Note 2591334 und Note
2144285 – R3load can produce duplicates at export if bulk fetch mode is active sind beispielsweise Zeugen eines solchen Vorfalls in Verbindung mit einer near-Zero Downtime Maintenance (nZDM) auf Basis von SAP ASE, SAP Hinweis 1724496 – Latest patches for R3-tools zeigt ein Problem speziell für Systemkopien, der in einigen Quellsystemen immer noch gültig sein kann. Einzelfälle sagen Sie? Gehen Sie mal auf die SCN Seite zur Database Migration Option und schauen Sie sich unten unter „Related SAP Notes/KBAs“ an, wie häufig da ein R3*Tool vorkommt.

Um es kurz und einfach zu halten: Aktualisieren Sie Ihren Kernel. Sie können beispielsweise unter NetWeaver 7.31 im Quellrelease von Kernel 7.21 auf 7.22 mit aktuellem Patchlevel gehen. Informationen zum Patchen des SAP Kernels erhalten Sie unter SAP Note 19466 – Downloading SAP kernel patches .

Selbstverständlich sollten Sie im Laufe des Projektes für alle Systeme einer Systemlinie immer die selben Kernel Files verwenden und nicht mitten im Projekt wechseln.

Halten Sie außerdem die SPAM aktuell. Es lohnt sich, vor einer SUM-Prozedur die SPAM zu aktualisieren – unter Umständen fordert Sie sogar der SUM dazu auf.

Parametertuning im Transportprofil

Auch wenn es nicht unbedingt die Parallelität Ihrer Upgrade-Prozedur stört, lohnt es sich im Rahmen der Vor- und Nacharbeiten zu prüfen, wie im Transportprofil Ihres Systems der Parameter ACC_IMPORT gesetzt ist. Es kann sein, dass Sie in der Vergangenheit aufgrund von Problemen mit dem parallelen Import bei der Nutzung von SPAM oder SAINT diesen Parameter gesetzt haben, um die Parallelität von SPAM/SAINT Importen auszuschalten. Dies schadet natürlich der Laufzeit Ihrer Vor- und Nacharbeiten. Weitere Informationen finden Sie unter SAP Note
1223360.

Weitere Transportprofil-PArameter wie beispielsweise „parallel=n“ haben auf die SUM-Prozedur ebenfalls kaum Einfluss, weil dieser seine eigenen tp Statements generiert jedoch können Sie auch hier für den Regelbetrieb sowie für den Import von Transporten in den Vor- und Nacharbeiten die Parameter aus dieser SAP Note entsprechend berücksichtigen.

Was jedoch auch auf die SUM-Prozedur einen Einfluss haben kann ist der Transportprofil-Parameter „generation=later“ (SAP Note 1069417), der dazu führt, dass der Import Step zur Load Generierung nicht ausgeführt wird. Auf sehr alten Systemen mit wenig Arbeitsspeicher lohnt es sich mitunter, über den Parameter „tcs“ nachzudenken, der die Größe des R3trans Table Caches bestimmt (SAP note 103582). Ich habe jedoch noch keinen Kunden gehabt, bei welchem dies notwendg war – bei den R3trans Prozessen war immer zuerst die CPU der Falschenhals, und nicht der RAM.

Wenn Sie sich für eine Performanceoptimierung für Ihren Regelbetrieb im Zusammenhang mit R3trans interessieren, sind außerdem die SAP Hiwneise 1309506 und 2655872 für Sie interessant.

Anzahl an Workprozessen (Dialog und Batch)

Datenkonvertierungsarbeiten des Software Update Manager, insbesondere die aus dem Postprocessing bekannten Konvertierungsarbeiten von Methoden wie XPRAs, XCLAs oder AIMs vorgenommen werden, hängen sich in Dialog- und Batch-Prozesse an. Die meisten dieser Tätigkeiten werden durch Dialogprozesse parallelisiert. Vor Start des Upgrades empfiehlt die SAP bei großen Systemen eine kofniguration von 20 Dialog und Batch Prozessen, zumindest für eine SAP S/4HANA System Conversion (SAP note 2351294). Dies kann zur Not in einem Conversion-spezifischen Betriebsmodus durchgeführt werden. Die SAP note stellt weiter unten sogar die Anzahl der parallelen ABAP Workprozesse für die SUM phase XPRAS_AIMMRG sogar auf 32. Man könnte also überlegen, zumindest die Anzahl der Dialogprozesse auf 32 zu erhöhen.

Als absolutes minimum MÜSSEN Sie zwei Batchprozesse haben. Führen Sie den SUM auf der PASI aus, sollten es sogar mindestens 5 sein.

Aber auch für SUM Prozeduren, die nicht mit einer S/4HANA System Conversion zu tun haben, führt eine Erhöhung der Anzahl an Dialog- und Batch-Prozessen zu einer Beschleunigung der Konvertierungsarbeiten.

Das ganze bringt natürlich nur was, wenn Sie in der SUM Phase PREP_CONFIGURATION/INITSUBST auch eine entsprechende Anzahl an ABAP PROCESSES (DOWNTIME) konfigurieren. Es bringt Ihnen nichts, wenn Sie auf Instanzebene die entsprechende Anzahl an Dialog- und Batchprozessen konfigurieren, Sie dem SUM aber nicht zur Nutzung übergeben.

Einspielen von SAP Notes oder Support Package Stacks

Das Einspielen von SAP Notes oder SPs vor einem eigentlichen Upgrade kann ebenfalls in Einzelfällen zu Performancegewinnen führen. Ein historisches Beispiel ist etwa SAP Note 1986362 – Improve BW & ERP Upgrade performance by not copying content texts, welches auch heute noch die Upgradezeit für den NetWeaver Release 7.40 reduzieren konnte. Für viele Kunden imer noch relevnat ist außerdem Note 2229248 – Long runtime in background job „RSUPGRCHECK“ during SAP EHP upgrade.

Insbesondere lohnt es sich, den aktuellen Hinweis für den Note Assistant einzuspielen (1668882 und evtl. die Vorab-Note 2248091). Dies führt eventuell zu Zeitgewinnen beim Einspielen von notes im Zuge der Vor- und Nacharbeiten und kann für die Folgesysteme in einem Transport festgehalten werden.

Dateisystem NFS für den Software Update Manager und das Transportverzeichnis

Die SAP empfiehlt Ihnen in SAP Note 1616401 explizit, für das „Upgrade Directory“, also das Verzeichnis des Software Update Manager, explizit kein NFS oder ein anderes netzwerkbasiertes Dateisystem wie etwa Windows SMB, sondern ein lokales Dateisystem zu nutzen. Macht ja auch Sinn, da dieser die ganze Zeit Logs schreibt und dieser Vorgang synchron mit der Anwendungslogik passiert. Das Verzeichnis für das Download Directory (in welchem die Softwarepakete und der Upgrade Export liegen) kann aus meiner Sicht ruhig auf einem netzwerkbasierten Dateisystem liegen.

Wenn Sie einen SMB-basierten Netzwerkshare unter Windows nutzen, prüfen Sie die Relevanz von SAP Note
1823833 – Accessing shares via SMB3.0 can result in long waiting times.

Wenn Ihr Transportverzeichnis über NFS bereitgestellt wird, sollten Sie dieses zumindest über NFS4 bereitstellen und mounten. Häufig werden Transportverzeichnisse noch auf Basis von NFSv3 bereitgestellt, wenn Sie in Ihrer Organisation ein UNIX-System verwenden. Sie können aber auch unter Unix häufig schon NFSv4 mounten. Setzen Sie in diesem Zusammenhang auch im Transportprofil den PArameter lock_check_wait_time=0 (SAP Notes 1223360 und 132536). Dies beschleunigt den Import von Transporten enorm. Unter Windows sollten Sie für das Transportverzeichnis „Opportunistic Locks“ deaktivieren (SAP Note 690449).

Speziell für Systemkopie und DMO sollten Sie außerdem SAP Note 2093132 – Recommendations for NFS parameters during System Copy konsultieren

Halten Sie Ihr Transportverzeichnis außerdem sauber. Archivieren Sie veraltete Transportaufträge und nutzen Sie den Befehl „tp clearold all“ (SAP note 312843).

Sie sollten während eines SUM-Laufes beispielsweise mit dem Windows Ressourcen Monitor oder mit dem Linux-Komamndozeilentool iotop die Auslastung der Dateisysteme überprüfen und sicherstellen, dass die Storage-Ebene bei Ihnen nicht zum Flaschenhals wird. sowohl unter Linux als auch unter Unix sind ebenfalls die Tools iostat, vmstat und sar.

Betriebssystem Limits und Quotas sauber einstellen bzw. erhöhen

User Limits sind vor allem auf Unix und Linux Applikationsservern ein Thema. Für AIX konsultieren Sie SAP Note 323816 – AIX: User limit settings .

Ein Beispiel, wie falsch konfigurierte Limits Fehler in einem SUM Upgrade hervorrufen können und wie man damit umgeht, liefert SAP Note 1563583.

Performanceverbesserung der ACT_UPG

Die Phase ACT_UPG ist bekannt aus der Tätigkeit des Modification Adjustment über die SPDD. Die eigentlich lange Phase ist jedoch die Aktivierungsphase nach der Bearbeitung dieser. Um eine Vorstellung über die Laufzeit der Aktivierungsphase in der ACT_UPG zu bekommen, kann der Report RADMASDSC genutzt werden. First things first: Stellen Sie sicher, dass im Quellrelease die folgenden SAP Notes für Sie nicht relevant sind:

• Quell-DB Oracle: SAP Note 1897538 – Long runtimes when accessing DD27S in ACT_UPG phase
• 2105466 – Performance problem during ACT_UPG or ACT_TRANS during update to SAP_BASIS 7.40 SP8 or SP9
• NW 7.40, Ziel-DB HANA: SAP Note 1855223 – Report RUTPOADAPT has a long runtime treffen.
• Quelldatenbank Oracle: 556764 – Upgrade hangs in phase ACT_<REL>
• Quelldatenbank Oracle: 1635605 – CLIENT HANGS ON INSERT INTO TABLE WITH SECUREFILE LOB
• Quell-DB DB2/390: 545281 – DB2/390: Performance of DD activation
• Quell-Release bis 7.31: 1614802 – Mass activation hangs during INSERT in the table DDFTX
• Quell-Release bis 7.31: 1631790 – Mass activation during transport is started repeatedly
• Quell-Release bis NW 7.3: 1892988 – DDIC_ACTIVATION phase takes too long in transaction SPAM/SAINT (auch für SUM)
• Quell-Release bis 7.31: 1798059 – Improvment of performance during component upgrade

Zentrale Note für das Performance Tuning der ACT_UPG ist Note 1674812. Wie bereits weiter oben erwähnt, sollten Sie für das Upgrade-Verzeichnis ein lokales Verzeichnis wählen, keinen NFS-Share.

Die Performance der ACT_UPG wird sehr stark von den Instanzprofilparametern der Schatteninstanz beeinflusst. Wo Sie diese Profile finden und wie sie heißen, wurde in der Vergangenheit bereits hier übersichtlich zusammengetragen.

Insbesondere sollten Sie die Hauptspeicherparameter der Schatteninstanz erhöhen, sofern möglich. Möglichst ist dies dann, wenn Sie in einem Probelauf des Upgrades keine Speicherengpässe feststellen. Sie sollten bereits beim Probelauf einen „educated Guess“ machen und das Ergebnis begutachten. Die wichtigsten Paramter lauten

• em/initial_size_MB
• abap/heap_area_toal
• abap/heap_area_dia
• abap/heap_area_non_dia
• ztta/roll_extension_dia
• ztta/roll_extension
• em/proc_max_size_MB = 0 (historisches Beispiel: SAP Note 2173629)
• rdisp/wp_no_dia

Im Zweifel können die Speicherparameter temporär für die Schatteninstanz in einem Testlauf auf einen absurd hohen Wert gesetzt werden, solange man den Parameter em/initial_size_MB richtig konfiguriert. Wenn Sie das jedoch machen, wird der Swap Speicher des Betriebssystems exzessiv genutzt werden. Konkrete Werte finden Sie etwa in SAP Note 1387739. Ein Feintuning im Laufe der Sytemlinie ist notwendig. Die SAP empfiehlt in SAP note 1674812, dass Sie die Anzahl an Dialogprozessen für die Schatteninstanz (rdisp/wp_no_dia) zwischen 10 und 15 halten.

Nach Anpassung der Parameter können Sie die Schatteninstanz neu starten über

../abap/bin/SAPup stopshd

../abap/bin/SAPup startshd

Wie Sie ein memory Bottleneck in der Schatteninstanz in dieser Phase erkennen, schildert Ihnen SAP Note
1275873 – Memory bottleneck during DDIC activation during EHP import. Diese ist übrigens auch gültig für Quellrelease SAP_BASIS <= 7.10.

Es lohnt sich, während der Aktivierungsphase in ACT_UPG die SM50 zu monitoren. Dort können Sie sehen, ob ein SQL Statement besonders lange dauert. Dies könnte ein Hinweis auf ein einzelnes teures SQL Statement sein, welches Sie eventuell durch einen Index Rebuild oder eine Aktualisierung der Datenbankstatistiken beheben können.

Überspringen der Phase JOB_RASUVAR2

Der Variantenretter besteht aus zwei Phasen, die durch zwei verschiedene Jobs abgewickelt werden. Eine Erläuterung der Logik erhalten Sie unter SAP Note 712297. RASUVAR1 läuft vor dem eigentlichen Upgrade in der Online-Phase und speichert die Varianten in einer Tabelle. Nach dem Upgrade wird eine auf dem Zielrelease basierende Version des Jobs RASUVAR2 angestartet, welches die Varainten aus der Zwischentabelle abholt und verarbeitet.

Grundsätzlich müssen Sie jedoch nicht während der SUM-Laufzeit warten, bis der Job RASUVAR2 fertig ist. Wenn Ihnen die Phase zu lange braucht, können Sie sie im SUM überspringen und im Laufe der Nacharbeiten anstarten, während Sie parallel andere Aufgaben am System wahrnehmen.

Wie Sie den Schritt überspringen, erfahren Sie in SAP Note 1052664.

Performanceverbesserung der Phase PARCONV_UPG

In der PARCONV_UPG (Zentrale Performance Notes: 1947797 und 2100132) finden die Konvertierungen von Tabellen statt, beispielsweise wenn Felder gelöscht wurden oder sich deren Datentyp geändert hat. Das ganze braucht seine Zeit, weil man quasi jede Zeile der Tabelle einzeln beispielsweise das neue Feld an diesen einen Datensatz dranhängen muss. Wenn hingegen Felder hinzukommen, geht die Sache schneller, was das mit Hilfe eines DDL Statements geschehen kann und in diesem Fall jede Zeile etwa mit einem Standardwert belegt werden kann. DDL Statements können jedoch auch lange brauchen, und zwar wenn ein Index auf eine große Tabelle aufgebaut wird.

First things first: stellen Sie sicher, dass die folgenden SAP notes nicht auf Sie zutreffen:

• Quellrelease bis SA_BASIS 7.11:
  1283197 – Cluster tables: Unnecessary conversion
• Quelldatenbank DB2-z/OS:
  1386557 – DB2-z/OS: Upgrade/EHPI with external index rebuild

Wenn Sie in der Phase PARCONV_UPG die Transkation SM50 verfolgen, sehen Sie die tabelle, die gerade konvertiertwird. Alle Tabellen, die in dieser Phase involviert waren, könne Sie über SE14 -> DB Requests -> Mass Processing finden. In der SE14 prüfen Sie auch für die jeweiligen tabellen den Fortschrit des Umsetzens.

Lang laufende Indexaufbaus in dieser Phase finden Sie beispielsweise über ST04 raus. Sie können dann versuchen, den Aufbau dieser Indizes zu verhindern, indem Sie eine der drei Lösungen aus SAP Note 2100132 – upgrade phase PARCONV_UPG running for extremely long time due to large indexes creation anwenden.

Wie verbessern Sie nun die Zeiten? Nun, die aller erste Maßnahme ist es, Tabellenkonvertierungen zu vermeiden. Das bedeutet im Endeffekt: Vermeiden von Feldlöschungen bzw. Änderungen von Datentypen. Dies können Sie durch Ihre Entscheidung in der SPDD beeinflussen. Wenn Sie beispielsweise ein Z-Datenfeld zu einer Tabelle bzw. einem Datenelement hinzugefügt haben und wissen, dass Sie dieses im Zielrelease nicht mehr brauchen, liegt die Entscheidung nahe, auf Standard zurückzusetzen und das Feld somit löschen zu lassen. Vielleicht wäre es aber im Hinblick auf die Downtime klüger, die Modifikation zu übernehmen und das Feld im Nachhinein nach Freigabe des Systems zu droppen. Das lohnt sich halt vor allem dann, wenn die Tabelle bzw. die Tabellen, in welchen das Datenelement genutzt wird, sehr groß sind. SAP Note 24864 – No conversion of the table BSEG zeigt anhand der Tabelle BSEG sogar, wie Sie unter bestimmten Voraussetzungen Konvertierungsschritte in dieser Phase überspringen können, solange die Quelltabelle noch nicht verändert wurde.

Selbstverständlich reduzieren Sie jedoch auch die Laufzeit einer Konvertierung und eines Indexaufbaus, indem Sie die Größe der jeweiligen Tabelle reduzieren. Effektive Wege hierzu zeige ich Ihnen in der Sektion zur Datenreduktion auf.

In gewissem Maße spielen auch die Anzahl der ABAP Prozesse und die der SQL Prozesse eine Rolle. Hierzu gebe ich Ihnen in einer anderen Sektion in diesem Bietrag entsprechende Hinweise. Jedoch merken Sie hier nur bis zu einer maximalen Anzahl von 8 parallelen Prozessen einen Perforamncegewinn.

zu guter letzt: Speziell für SAP BW Systeme sollten Sie nach SAP Note 1420163 – Long runtimes for table conversion in Betracht ziehen.

Performanceverbesserung der Phasen SHADOW_IMPORT_INC und TABIM_UPG

Zentrale Einstiegs-Note ist 1945399. Während die SHADOW_IMPORT_INC eine Uptime Phase ist, ist die Phase TABIM_UPG eine Downtime-Phase. Diese beiden Phasen werden direkt durch die Parallelität von R3trans Prozessen beeinflusst, zu deren Sizing ich Ihnen an anderer Stelle in diesem Beitrag entsprechende Hinweise gebe.

Wie schnell die einzelnen R3trans-Importe sind, können Sie messen. In der Phase SHADOW_IMPORT_INC werden beispielsweise Logsim Format SAPKB<release>.<SID> erzeugt. Dort finden Sie Laufzeitangaben vor. Lang laufende SQL Statements in dieser Phase können Sie außedem über die Transaktion ST04 rausfinden.

Weitere Faktoren, welche die Performance dieser Phasen beeinflussen, sind:

• I/O für Lese- und Schreibgeschwindigkeit im SUM-Verzeichnis (hierzu die Hinweise bezüglich netzwerkbasierte Dateisysteme in diesem Beitrag beachten)
• I/O für Lese- und Schreibgeschwindigkeit auf der Datenbank. Deswegen sollten Sie in diesen Phasen explizit auf ein Full Online Backup der Datenbank verzichten.
• Datenbank-Performance (datenbankspezifische Hinweise in diesem Beitrag beachten)
• Die Anzahl an Support Packages, die Sie für das Upgrade mit ausgewählt haben (je mehr R3trans importieren muss, desto länger dauerts halt. Was aber nicht heißen soll, dass Sie deswegen weniger SPs in Ihre stack.xml integrieren sollten).

Sie sollten während eines SUM-Laufes beispielsweise mit dem Windows Ressourcen Monitor oder mit dem Linux-Komamndozeilentool iotop die Auslastung der Dateisysteme überprüfen und sicherstellen, dass die Storage-Ebene bei Ihnen nicht zum Flaschenhals wird. sowohl unter Linux als auch unter Unix sind ebenfalls die Tools iostat, vmstat und sar.

Performanceoptimierung der XPRAS-Phasen

Wie bereits schon an anderer Stelle erwähnt, wird die Performance der XPRAS-Phasen wie beispielsweise XPRAS_AIMMRG stark durch die Anzahl der parallelen ABAP- und SQL-Prozesse beeinflusst, und diese wiederum durch die Anzahl der Dialog- und Batch-Prozesse auf der Instanz.

First things first – prüfen Sie, ob folgende SAP Notes für Sie relevant sind:

• Quelldatenbank MS SQL, SUM 1.0: 1780056 – SUM on MSS: Long running XPRAS phases
• Quelldatenbank DB2, SAP_BASIS <=731: 1442150 – RUN_RSAIMMERGE_TRANSFER: Long runtime during upgrade or EHPI
• Notes für Deadlocks, die auch in der XPRAS aufkommen können:
  1155807 – Database deadlock when executing DD_INT_UPDATE_DDFTX und
  1614802 – Mass activation hangs during INSERT in the table DDFTX
• SAP_BW bis Release 7.31: 1722205 – Deactivate creation of pseudo D version during transport

Zentrale Note zur Performance-Analyse ist Note 1947874. Eine Performance-Analyse ist grundsätzlich über die SM50möglich. Dort sehen Sie die Workprozesse, die lange laufen. Von diesen müssen Sie sich den Namen des ausgeführten reports, die After-Import-Methode und den Namen der Tabelle, auf die zugegriffen wird, notieren.

Wenn es sich bei den Reports um BW Reports handelt, gibt es einige SAP Notes zu berückscihtigen. SAP Note
1649901 – Time-critical processes in BW upgrade/Support Package können Sie schon fast proaktiv als Vorarbeit implementieren (nicht auf BW Systemen, sondern auch auf anderen Systemen mit BI Content). Sie können die Aktivierung des BW Technical Content sogar komplett überspringen und als Nacharbeit nach dem Upgrade durchführen, siehe SAP Note 1629923 – Skip BW technical content objects activation during upgrade .

Performanceoptimierung der PARMVNT Phasen

In der Phase PARMVNT_SHD werden durch das Kommandozeilentool tp Tabellen erstellt oder geändert, was nicht zu verwechseln ist mit der PARCONV_UPG, die wir weiter oben erwähnt haben. Die PARCONV_UPG führt Änderungen auf Basis der Entscheidungen in der SPDD durch und bezieht sich daher auf Datenelemente, Strukturen und Domänen, die PARMVNT_SHD arbeitet direkt auf Datenbankebene und bezieht sich auf interne Releae Logik. Die SQL Statements für die PARMVNT_SHD werden in der Phase PARDIST_SHD generiert.

Das heißt, im Gegensatz zur PARCONV_UPG können Sie die Statements, die ausgeführt werden sollen, nicht so gut beeinflussen. Wann immer in dieser Phase ein tp Prozess aktiv ist, können Sie das teure SQL Statement über die Transkation ST04 (in der Originalinstanz, nicht in der Schatteninstanz) heraus finden.

Sie können prüfen, ob auf der Tabelle DDNTT~ ein Index auf den Primärschlüssel existiert. Falls nicht, kann dies ein Grund für lange Laufzeiten sein, weil dann ein Full Table Scan erfolgen muss. Unter Oracle können Sie prüfen, ob das DELETE Statement aus SAP Note 1960112 sehr lange braucht, um einen Hinweis darauf zu erhalten, dass es Probleme mit dem IOndexaufbau geben könnte.

Datenbankspezifische Maßnahmen

Aktualisieren / Patchen von Datenbankservern und Datenbankclients

Der Einfluss auf die Performance kann von kaum erkennbar über marginal bis hin zu extrem sein, je nachdem, welche Datenbank Sie einsetzen. Grundsätzlich empfiehlt es sich immer, nach Möglichkeit vor einem Upgrade-Projekt in einer Art „Mini-Downtime“ den Quelldatenbankserver sowie die Datenbank-Clients (sowohl auf dem Datenbankserver selbst als auch auf den Applikationsservern) zu patchen bzw. aktualisieren. Das heißt unter Oracle beispielsweise den aktuellen Bundle Patch einspielen und den Instant Client zu aktualisieren.

Besonders groß kann der Performanceunterschied bei DB6-Updates werden. Konsultieren Sie hierzu SAP Note
101809 – DB6: Supported Db2 Versions and Fix Pack Levels. Für Patches einer Oracle 12 Datenbank konsultieren Sie Note 1915316, für Oralce 11 gibt es fünf unterschiedliche Notes für 11.2.0.2-11.2.0.5. Ein historisches Beispiel, warum Sie Ihre Oracle Datenbank patchen sollten, finden Sie beispielsweise in SAP Note 1738989. Informationen zum Upgrade von SAP ASE auf Business Suite Systemen finden Sie unter 2238127 – How to upgrade ASE in a Business Suite environment – SAP ASE for Business Suite

Aktualisieren der Datenbankstatistiken

Sofern die von Ihnen eingesetzte Quelldatenbank dies nicht bereits automatisch optimiert, sollte Sie vor dem Upgrade auf den Systemen eine Aktualisierung der Datenbankstatistiken einplanen. Optimalerweise tun Sie dies ohnehin schon in einem regelmäßigen Turnus. Die Datenbankstatistiken stellen sicher, dass die Datenbank zum Erstellen des Ausführungsplans für ein SQL Statement möglichst aktuelle Datenbankstatistiken zur Ermittlung dieses optimalen Weges erhält. Je besser der Ausführungsplan, destobesser auch die Durchführung des Statements – was sich wiederum in der Performance auswirkt.

Ein Beispiel dafür, dass die Aktualisierung von Datenbankstatistiken im Zuge eines Upgrades etwas bringen kann, liefert SAP Note 1232776 – Long runtimes for accesses to D010INC or D010TAB.

Reorganisation der Datenbank

eine Reorganisation der Datenbank hat häufig einen geringeren Performanceeinfluss als gedacht, vor allem in OLTP Datenbanken. Dies wird beispielsweise in SAP Note 159316 – Reorganization of tables on SQL Server erwähnt. Ob Ihnen also eine Reorgnaisation der Datenbank vor einem Upgrade oder einer Migration wirklich einen signifikanten Vorteil verschafft, ist fraglich. In OLAP Szenarien, sprich unter SAP BW, ist dies wesentlich wahrscheinlicher als in einem OLTP Szenario.

Parametrisierung einer Oracle Datenbank

Für die verschiedenen Oracle Releases (meistens werden Sie jedoch zwangsläufig vorher auf Oracle 12c gehen müssen, wenn Sie eine bestimmte SUM-Prozedur ausführen wollen) gibt es jeweils unterschiedliche Notes zur Optimierung der Parametrisierung. Die folgende Tabelle listet die einzelnen Notes auf. Neben den Notes bringt außerdem die Vergrößerung des Tablespaces PSAPTEMP einen Performancegewinn. Sie verspüren einen Performancegewinn, indem Sie den PSAPTEMP vergörßern, bis auf maximal 20-30 % des Statements select sum(bytes) from dba_segments. Auch nützlich ist es, den Tablespace PSAPROLL auf bis zu 20 GB anzuheben.

Bevor sie ein Upgrade starten, haben Sie aeßerdem unter Oracle die Möglichkeit, die Phasen EU_CLONE_DT_SIZES und EU_CLONE_UT_SIZES zu unterdrücken. Während dieser Phasen werden normalerweise die Datenbankstatistiken über den Speicherverbrauch der Tabellena ktualisiert. Dadurch soll das Table Splitting verbessert werden. Häufig ist die Laufzeit jedoch höher als die Einsparung (insbesondere, wenn Sie die Datenbankstatistiken kurz vorher noch manuell aktualisieren), und Sie können mit den folgenden Statements diese Phasen unterdrücken.

brconnect -u / -c -f stats -t oradict_stats -p 8

brconnect -u / -c -f stats -t system_stats -p 8

brconnect -u / -c -f stats -o <schema_owner> -t all -f allsel,collect,space -p 8 -c 5 -force

brconnect -u / -c -f stats -t all -f monit -p 8

Damit die Phase wirklich auch noch übersprungen wird, müssen Sie im SUM Verzeichnis in der Datei SAPup_add.par noch den Parameter /ORA/update_spacestat = 0 setzen.

Parametrisierung einer Sybase Datenbank

Parametrisierung von MS SQL Server

Parametrisierung einer MaxDB

Parametrisierung einer DB2/DB6 Datenbank

Performanceoptimierung einer HANA Datenbank

HANA Datenbankparameter für die Downtime

Wir sprechen hier über die HANA Ziel-Datenbank. Wenn Sie eine Migration von einer HANA Datenbank in eine andere machen, müssen Sie die hier erwähnten Parameter in der Zieldatenbank tätigen. Diese Parameter sind explizit aus der Downtime. Sie verkürzen die Zeit für XPRAs, XCLAs und AIMs, welche insbesondere im Postprocessing angewandt werden, sowie die Dauer von Deltamerges, die im Rahmen des Shadow Importes und im rahmen der Datenmigrationen in den Nacharbeiten auftreten. Sie gehen hervor aus SAP Note 2351294. Ich erhebe keinen Anspruch auf Aktualität, deshalb immer wirklich die entsprechende Note konsultieren. wie in der Note erläutert, können Sie die Parameter so lange stehen lassen, bis sie in den Nacharbeiten die Datenmigrationen über die SPRO abgeschlossen haben.

Deaktivieren des Log Archivings und Redo Log Mirrorings zur Downtime

Die meisten Kunden machen das ohnehin schon, daher halte ich diesen Tipp relativ kurz. Kurz vor Eintritt der Downtime werden Sie durch den Software Update Manager ohnehin aufgefordert, das Log Archiving auf der Datenbank auszuschalten. Dies sollten Sie nicht nur beim Upgrade, sondern auch bei der Migration, beispielsweise per Systemkopie machen. Voraussetzung ist natürlich, dass Sie vor Eintritt in die Downtime ein vollständiges Datenbankbackup erstellt haben.

Nicht nur das Log Archiving können Sie ausschalten, sondern gleichzeitig auch das Redo Log Mirroring. Wenn Sie beispielsweise Ihre Oracle Redo Logs auf mehrere Datenträger spiegeln, muss eine Transkation warten, bis sie auf beiden Datenträgern persistiert wird. Das beeinträchtigt natürlich die Performance.

SGEN nicht während der Downtime durchführen

Der Software Update Manager gibt Ihnen sowohl bei Upgrade als auch bei einer DMO die Möglichkeit, die „Load Generation“ während der Downtime durchzuführen. Besser ist es, Sie starten die SGEN einmal manuell nach Abschluss des Software Update Managers an und lassen sie Prozedur online als Hintergrundjob laufen. Dann müssen Sie die Dauer der SGEN nämlich nicht als technische Downtime draufschlagen und können nebenbei einige Nacharbeiten machen, was die Business Downtime verkürzt.

Warum empfiehlt Ihnen die SAP das nicht? Nun, weil es bei Business Server Pages sein kann, dass Sie die Generierung mehrfach durchführen müssen, und Sie es außerdem vermeiden sollten, die SGEN abzubrechen (insbesondere im Zusammenhang mit BSPs). Deswegen empfehle ich Ihnen, die SGEN erst anzuschalten, nachdem Sie ein Backup des fertig upgegradeten Systems gemacht haben, auf welchem nur noch die Nacharbeiten durchgeführt werden müssen.

Sollten Sie die Option zur Ausführung der SGEN während des Upgrades ausgewählt haben und diese läuft nun gerade unerwartet lange, können Sie die SGEN manuell über den Report RSUPG_SGEN_ABORT_SHADOW abbrechen und somit zum nächsten Schritt des Upgrades fortschreiten.

Übrigens: ein frischer SGEN VOR dem Upgrade kann die Laufzeit desselben reduzieren. Meistens ist der Gewinn jedoch marginal.

Rebuild bestimmter Indizes

Bei Oracle Quelldatenbanken kann es sinnvoll sein, im SAP Business Suite Umfeld bestimmte Indizes online neu aufzubauen, bevor der Export der Daten stattfindet. Diese verbessern eventuell die Performance von Tabellenkonvertierungen eines Upgrade bzw. von Exporten bei einer Systemkopie oder DMO. Die folgende Liste zeigt ein Beispiel.

alter index SAPDAT.“VBFA~M01~ REBUILD ONLINE COMPRESS PARALLEL 3;

Was ist eigentlich, wenn Sie Daten nicht aus einer Oracle Datenbank exportieren, sondern importieren, beispielsweise wenn Sie auf eine Oracle 12c Zieldatenbank migrieren, etwa im Rahmen einer Systemkopie?

In diesem Fall können Sie das ALTER Index Statement dazu nutzen, die Fortschreibung von Indizes für die Zeit des Imports auszuschalten. Wenn Sie verhindern, dass Indizes mitgeschrieben werden, hat die Oracle mehr I/O für das Schreiben der eigentlichen Produktivdaten zur Verfügung. Dadurch geht der Import schneller. Sie können die Indizes dann später in der Uptime online rebuilden. Dadurch haben Sie effektiv die Importzeit und damit die Business Downtime reduziert.

Setzen Sie zunächst vor dem Import die Indizes auf unusable. Ein Beispiel im ERP Umfeld könnte sein

alter index SAPDAT.“MSEG~M“ UNUSABLE;

alter index SAPDAT.“MSEG~R“ UNUSABLE;

alter index SAPDAT.“MSEG~S“ UNUSABLE;

alter index SAPDAT.“ACCTIT~1“ UNUSABLE;

alter index SAPDAT.“COEP~1“ UNUSABLE;

alter index SAPDAT.“EDIDS~2“ UNUSABLE;

alter index SAPDAT.“EDIDS~1“ UNUSABLE;

alter index SAPDAT.“JITIT~001“ UNUSABLE;

alter index SAPDAT.“JITIT~002“ UNUSABLE;

alter index SAPDAT.“JITIT~003“ UNUSABLE;

alter index SAPDAT.“JITIT~004“ UNUSABLE;

alter index SAPDAT.“JITIT~005“ UNUSABLE;

alter index SAPDAT.“JITHD~001“ UNUSABLE;

alter index SAPDAT.“JITCO~001“ UNUSABLE;

Starten Sie nun den Import. Nach der Downtime, wenn die Migration abgeschlossen ist und das System schon wieder läuft, rebuilden Sie die Indizes. mit dem oben erwähnten Statement.

Optimierung der Perfomrance einer S/4HANA System Conversion

Parameter in der Tabelle MFLE_PARAMS

Im Rahmen einer System Conversion nach SAP S/4HANA wird der Converison Report
MFLE_XPRA_PARALLEL_CALL ausgeführt, welcher sich um die Konvertierung aller Tabellen mit dem Datenelement MATNR auf die neue „lange Materialnummer“ (LAMA) mit 40 Zeichen kümmert. . Über das Tuning der Parameter in der tabelle MFLE_PARAMS (SAP Note 2355049) kann die Performance dieses Reports gesteigert werden. Weitere Tuning Parameter, die auch diesen Report betreffen, finden Sie in SAP Note 2351294, die der folgenden Sektion behandelt wird.

Parameter in der Tabelle SHDB_PFW_CONF

Während der SUM Phase CHECK4NOTES_TOOL_SHD2 empfiehlt es sich, zur Beschleunigung einer Reihe von Conversion Reports gemäß SAP Note 2351294 ab einem Zielrelease von SAP S/4HANA 1709 oder höher bestimmte Parameter in der Tabelle SHDB_PFW_CONF zu setzen. Hierzu sollten Sie einen Breakpoint auf die Phase CHECK4NOTES_TOOL_SHD2 setzen (SAP Note 2207944) und dann die in der note gelisteten Kommandos ausführen.

Aktuell lauten die Befhele sowohl für Zilrelease 1709 als auch 1809 wie folgt

INSERT INTO SHDB_PFW_CONF (APPL_NAME,COMPONENT,PARAM,TYPE,LENGTH,DECIMALS,VALUE,CHANGEABLE) VALUES (‚XCLA_PROCESSING‘,’RESOURCE PROVIDER‘,’ABAP_MAX_WP‘,’I‘,4,0,‘32‚,‘N‚);
INSERT INTO SHDB_PFW_CONF (APPL_NAME,COMPONENT,PARAM,TYPE,LENGTH,DECIMALS,VALUE,CHANGEABLE) VALUES (‚XCLA_PROCESSING‘,’DISPATCHER‘,’WAKEUP_INTERVAL‘,’I‘,4,0,‘1‚,‘N‚);

Diese beiden Statements wiederholen Sie nun für alle Prozeduren in den Tabellen (Spalte APPL_NAME aus Note 2351294). Beachten Sie: Die Ausführungen für den Release 1709 gelten auch für Zielrelease S/4HANA 1809.

Sie sollten dabei achten, dass die Anzahl an maximalen Prozessen nicht dazu führt, dass CPU, Storage I/O oder Arbeitsspeicherkapazität mehr als 90% beansprucht werden. Sie sollten während der jeweiligen SUM Phase (Spalte SUM Phase in der Tabelle der Note, meistens XPRAS_AIMMRG) die Utilization von CPU, Storage und Arbeitsspeicher überwachen und prüfen, ob Sie die Parameter richtig gewählt haben.

Natürlich bringt Ihnen das Einstellen mehrerer ABAP Workprozesse nur was, wenn Sie die entsprechende Anzahl an Workprozessen auch auf der Instanz zur Verfügung haben.

Parallele Ausführung von SD Reports

SAP Notes 2353814 bzw. 2351294 befassen sich mit der Parallelisierung von Datenkonvertierungsprogrammen im SD-Umfeld während einer S/4HANA System Conversion. Die Verbesserungen sind im Prinzip sehr einfach zu implementieren, da sie im Endeffekt immer nur über die SE16 einige Einträge in bestimmten Tabellen ändern müssen.

Optimierung der DMO und Systemkopie Performance

Die hier gelisteten Aktivitäten verbessern vor allen Dingen die Performance einer Database Migration Option und der heterogenen Systemkopie. Sie sind explizit dafür vorgesehen und haben keinen oder nur einen sehr geringen Einfluss bei der Upgrade-Performance.

Die DMO auf einem leistungsstärkeren AAS laufen lassen

Bis einschließlich SUM 1.0 SP20 war es nur möglich, eine DMO auf dem eigentlichen Primary Application Server (PAS) laufen zu lassen. Häufig bedeutete dies automatisch eine hohe Einschränkung in der Performance, das die Maschine häufig schon sehr alt und mitunter nicht virtualisiert ist. Außerdem wird der PAS häufig während der technischen Uptime-Phase zusätzlich durch den Grundbetrieb belastet. Nun ist es möglich, Die DMO grundsätzlich auf einem Additional Application Server (AAS) laufen zu lassen. Dadurch wird der PAS entlastet und man profitiert eventuell auch von einem leistungsfähigeren Host. Leider funktioniert die Prozedur nur auf Quellsystemen, die bereits eine getrennte ASCS Instanz aufgebaut haben. Wenn Sie noch keinen ASCS/PAS Split durchgeführt haben, prüfen Sie, ob Sie diesen im Quellrelease durchführen können.

Netzwerkbandbreite und Jumbo Frames

Speziell im Umfeld einer Database Migration Option oder einer Systemkopie mit parallelem Export/Import ist es wichtig, dass die Netzwerkbandbreite ausreichend ist, um eine entsprechende Migrationsgeschwindigkeit zu stemmen. Ein dediziertes 10 Gbit/s Netzwerk sollte bereits genügend Bandbreite für eine Migrationsgeschwindigkeit von 3500 GB/h liefern, jedoch ist dies nicht praxianah, da häufig auch andere Komponenten im Netzwerk sind. Die SAP empfiehlt für eine DMO zwischen den Hosts auch mindestens ein Netzwerk, in welchem alle Komponenten die 10 Gbit/s liefern können. Explizit nicht unterstützt von der SAP ist eine DMO „across data centers“, also zwischen zwei Rechenzentren. Dies sollten Sie also in der Planung bereits vermeiden.

Es ist definitiv eine Überlegung wert, für den Zeitraum der Migration Quell- und Ziel-Datenbank in ein und das selbe Netzwerksegment ohne Firewalls dazwischen zu packen, um die Netzwerkbandbreite zu erhöhen. Andererseits erzeugt dies zusätzlichen Aufwand, weil Sie diese Konfiguration nach der Migration dann umstellen müssen. Besser ist es, sicherzustellen, dass die Netzwerkbandbreite nicht zum Flaschenhals wird, indem man vorher sauber architektonisch designt und sized.

Unter Umständen könnte es Ihnen auch einfallen, Jumbo Frames auf den Hosts zu konfigurieren. Seien Sie damit jedoch vorsichtig. Jumbo Frames können auch eine Fehlerursache sein, die nur sehr schwer zu finden ist. Sie hat damit gleichzeitig einen hohen Business Impact, denn damit das Ganze funktioniert, müssen

• alle beteiligten Netzwerkkarten
• Router und Firewalls
• Nebengeräte (wie beispielsweise Netzwerkdrucker)

mit diesen Frames umgehen können. Auch softwareseitig kann es zu Problemen kommen. Unter SAP HANA 1.0 gab es vom Hersteller dokumentierte Fälle, in denen die Konfiguration von Jumbo Frames zu Fehlern geführt hat (z. B. SAP note 2166157).

SUM Benchmarking Tool

Wenn Sie den Software Update Manager aufrufen, können Sie das DMO Benchmarking Tool unter https://<hostname>:112[8|9]/lml/migtool/<sid>/doc/sluigui aufrufen. Dort angekommen haben Sie die Möglichkeit, den Export und Import von Daten zu prüfen.

Grundsätzlich ist die Konfiguration des Tools für eine Database Migration Option optimiert. Das heißt Sie geben die Systemdaten der Zieldatenbank ein, und der Software Update Manager führt dann probeweise die Prozedur eines parallelen Export/Imports durch. Natürlich ist dieser Benchmark aber zeitgleich auch ein Nachweis für die Performance eines parallelen Export/Imports bei einer Systemkopie.

Wählen Sie zunächst den Menüpunkt „Benchmark migration“. Als ersten Ansatz sollten Sie immer versuchen, den Export der Quelldatenbank zu optimieren. Dazu empfiehlt es sich, im Benchmark Tool zunächst den Menüpunkt „Benchmark Export (discarding data)“ zu wählen.

Starten Sie den Export auf einem kleinen Prozentsatz der Systemtabellen. SAP selbst empfiehlt mindestens 100 GB, jedoch maximal 10% der Quelldatenbankgröße. Den ersten Lauf sollten Sie komplett ohne irgendwelche Optimierungen in der Quelldatenbank durchführen. Danach führen Sie schrittweise Optimierungen durch und testen deren Auswirkungen auf die Export-Performance, indem Sie den Lauf wiederholen.

Im Feld „Size of largest table in sample“ legen Sie fest, wie große eine Tabelle maximal sein darf, um in den Benchmark mit aufgenommen zu werden. Wenn ihre Datenbank 100 GB groß ist und Sie 1% wählen, werden keine Tabellen selektiert, die größer als 1 GB sind. Das ist natürlich nicht repräsentativ. Sie wollen durchaus auch größere Tabellen benchmarken, um kein „unrealistisch positives“ Ergebnis zu bekommen. Andererseits wollen Sie aber auch keine zu großen Tabellen selektieren, da diese als „Ausreißer“ die Statistik in das negative verfälschen. Eine Tabellengröße von 100 GB als Maximum anzustreben ist auch hier ein guter Richtwert.

Setzen Sie den Haken bei „Enable Migration repetition“, um auf einfache Art und Weise den Test wiederholen zu können.

Im nächsten Fenster setzen Sie beim ersten Lauf eine hohe Anzahl an R3load Prozesse, um eine entsprechende Anzahl an Buckets für das Table Splitting zu erzeugen. Dadurch, dass Sie viele Buckets erzeugen, können Sie später besser mit mehreren R3load Prozessen hantieren und somit bestimmten, welche Anzahl bei Ihnen optimal ist. Sie können es ruhig übertreiben und die 10-fache Menge an Kernen bzw. virtuellen CPUs auf dem System nutzen.

Bevor Sie auf den Button „Execution“ klicken, reduzieren Sie wieder die Anzahl der R3loads, indem Sie den Wert auf einen empfohlenen Wert einstellen. Das geht im SUM Menü unter More -> Utilities. Ein guter Einstiegswert ist die doppelte Menge an CPU Kernen auf dem Host. Auf den meisten Systemen können sie das sowohl für Downtime als auch für die Uptime konfgurieren. Nur, wenn bei einer Testmigration im Online-Betrieb ein Impact auf die Performance auffällt, sollten Sie für die Uptime weniger wählen.

Starten Sie nun den Benchmark. Monitoren Sie während der Ausführung die Auslastung der CPU und die Auslastaung der Netzwerkbandbreite. Diese sollten, wie weiter unten nochmal beschrieben, eine Auslastung 90% nicht überschreiten. Wiederholen Sie den Schritt so oft Sie wollen und führen Sie irgendwann nicht nur einen Export, sondern auch einen Import aus. Spielen Sie mit den R3load Prozessen, bis Sie einen optimalen Wert erzielt haben, der Ihnen eine kontinuierliche CPU- oder Netzwerk-Auslastung (was auch immer der Flaschenhals bei Ihnen ist) zwischen 80 und 90% beschert. Der Arbeitsspeicher sollte ebenfalls nie komplett voll sein, um Paging zu vermeiden. Ein R3load Prozess benötigt mindestens 60 MB, jedoch auch gerne mal mehr.

Nachdem Sie den Export ausführlich optimiert hatten, sollten Sie eine komplette Migration benchmarken, also auch den Import. Hierbei macht es Sinn, den Menüpunkt „Operate on all tables“ zu wählen bzw. die DB size und die largest Table Size auf 100% zu setzen und daher keine Einschränkung über die Tabellen mehr zu machen. Für weitere Optimierungsmaßnahmen in dieser Benchmark-Phase können Sie nun im nächsten Kapitel weiter unten weiterlesen.

Nachdem Sie die komplette migration gebenchmarkt haben, können Sie sdas ergebnis über das Summary Log unter SUM/abap/log/EUMIGRATERUN*.LOG auswerten. Das Log zeigt Ihnen unter anderem den Migration Speed in GB/h an. Von einer guten Migrationsgeschwindigkeit spricht man ab 300 GB/h, erstrebenswert sind 500 GB/h. Im sogenannten Durations File unter SUM/abap/htdoc/MIGRAT*_DUR.XML findne Sie die graphische Repräsentation der Laufzeiten einzelner migrierter Tabellen. Suchen Sie hier Langläufer am Ende der Migrationsphase. Wenn Sie eine langlaufende Tabelle finden, analysiseren Sie die Datei SUM/abap/log/MIGRATE_RUN*.LOG und suchen Sie nach dem Namen der tabelle. Analysieren Sie

Zusätzlich können Sie zur Auswertung im SUM unter „DMO Migration Post Analysis -> Charts“ die Datei „MIGRATE_*PROC*“ auswählen und dadurch die Auslastung der R3load Prozesse analysieren. Sie sollten einen „tail“ im Graphen der R3load Auslastung vermeiden.

Anzahl an ABAP, SQL, R3trans und R3load Prozessen

Anzahl der R3load Prozesse

Fangen wir mit den R3load Prozessen an. Sie sind zuständig für die Kopie des Original-Repositorys auf das Schatten-Repository und bestimmen somit die Geschwindigkeit zum Aufbau der Schatteninstanz. Außerdem werden Sie in der Downtime-Phase einer Database Migration Option für den Shadow Import von der Quelldatenbank in die Ziel-Datenbank (meistens SAP HANA) verwendet. Sie bestimmen also an zwei kritischen Punkten des Upgrades die Geschwindigkeit ungemein.

Die R3load Prozesse für die UPTIME werden für folgende Tätigkeiten benutzt

• Kopieren der Schattentabellen in das Shadow Repository der Schatteninstanz.
• Bestimmen der Tabellen für den Export während der Downtime

Die R3load Prozesse für die DOWNTIME werden für folgendes genutzt

• Export und Import der Tabellen während des Shadow Imports

Grundsätzlich sollten Sie nur so viele R3load Prozesse konfigurieren, dass die CPU gemäß Betriebssystem-Monitor nie mehr als 90% ausgelastet ist. Eine 100%-ige Auslastung der CPU verschlechtert eher die Performance des R3load Vorgangs, daher sollte man sich bei etwa 90% auspendeln. Selbiges gilt für die Netzwerkbandbreite und den Storage. Sie können beispielsweise unter Linux mit „top“ die Auslastung während eines Benchmarks oder einer Migration auf einer Sandbox kontinuierlich in der Konsole verfolgen. Mit „iftop“ können Sie unter Linux den Netzwerktraffic monitoren. Mit „iotop“ überwachen Sie die Auslastung der Persistenzschicht. Unter Windows können Sie die Überwachung über den Task Manager vornehmen. Auch solten Sie mit den R3load-Prozessen nie den Arbeitsspeicher voll machen, so dass es zum Paging in den virtuellen Speicher bzw. in den Swap kommt. rechnen Sie grob pro R3load Prozess mit 60 MB RAM.

In SAP Note 1616401 heißt es, man solle als groben Richtwert die 3- bis 5-fache Menge an verfügbaren CPU-Kernen im System verwenden. Das heißt im Endeffekt die SAP gibt Ihnen hier Spielraum: 5-fache Menge, wenn Sie sicher sind, dass andere Faktoren wie beispielsweise RAM und Netzwerk nicht zum Flaschenhals werden, und die 3-fache Menge, wenn Sie auf Nummer sicher gehen wollen. In SAP Note 2643221 bzw.
2691785 (ja ich weiß, diese sind bezogen auf einen bestimmten SUM 1.0 Release) und 857081 heißt es wiederum, Sie sollen lediglich die zweifache Menge nehmen. In SAP Note 1875778 ist wiederum explizit von der dreifachen Menge die Rede. Aus meiner Sicht sind das eben nur grobe Richtwerte, und ein genaueres Sizing über das SUM Benchmark Tool, welches ich an anderer Stelle erwähne, bringt Sie näher an den optimalen Wert heran.

Monitoren Sie die Werte sowohl auf dem Applikationsserver (Export) als auch auf dem SAP HANA Host (Import).

ABAP Prozesse

Kommen wir nun zur Anzahl der ABAP Prozesse. Wie bereits weiter oben in der Überschrift Anzahl an Workprozessen (Dialog und Batch) erläutert, benötigen Sie erstmal auf dem System die notwendige Anzahl an Batch- bzw. Dialogprozessen. Es bringt Ihnen nichts, in dieses Feld 200 ABAP Prozesse einzutragen, wenn Sie die entsprechenden Workprozesse nicht auf der Instanz haben. Umgekehrt müssen Sie aber auch die Anzahl an Workprozessen, die Sie durch den Software Update Manager belegen wollen, dann auch tatsächlich in dieses Feld eingeben. Diese Option bestimmt auch die Anzahl an Hintegrundprozessen zur Aktiiverung über das Kommandozeilentool tp.

Eine möglichst hohe Anzahl an parallelen Dialogprozessne wird vor allem in der SUM Phase XPRAS_AIMMRG relevant. Eine möglichst hohe Anzahl an Batchprozessen wird vor allen Dingen während jobgesteuerter SUM Phasen wie DBCLONE, ACT_UPG, PARDIST und XPRAS relevant, auch wenn viele dieser Prozesse maximal 10 parallele Batchprozesse berhaupt bedienen können. Während der Uptime können Sie nur so viele ABAP prozesse konfigurieren wie verfügbar (wenn Sie mehr eingeben, bringt das nichts).

Die Batchprozesse bekommen Sie nur, wenn Sie die Batchprozesse nicht nur „live“ in der Betriebsart zur Verfügung haben (also während der Uptime in der SM50 bzw. RZ04 angezeigt bekommen), sondern auch der Parameter rdisp/wp_no_btc diese Nummer hergibt.

Sie sollten diesen Wert grundsätzlich so hoch stellen, wie es geht. Wenn Sie sich alle Tipps aus diesem Beitrag ansehen, kommen Sie irgendwann auf 32 Prozesse

SQL Prozesse

dieAnzahl der SQL Prozesse bestimmt die Anzahl an parallelen SQL Statements auf der Datenbank, speziell in den DDL Phasen wie MVNTAB und PARCONV, in welcher viele Statementsim Format „CREATE TABLE“, „ALTER TABLE“ und „CREATE INDEX“ abgsetzt werden. Empfohlen wird hier gemäß SAP note 1616401 die Anzahl physikalischer CPUs

R3trans Prozesse

Diese Parameterangabe wird nicht nur für die Anzahl der parallel ausführbaren R3trans, sondern auch für die tp Prozesse genutzt. Wenn Sie hier optimal treffen, beschleunigen Sie den Import von allen Softwarepaketen in das Schattenrepository, die nicht im Upgrade Export vorhanden sind. Je höher das Delta zwischen Upgrade Export und im Zielrelease enthaltenen Support Packages, desto höher der Effekt, wenn Sie hier richtig optimieren. Insbesondere beschleunigen Sie hier die Phasen DDIC_UPG, SHADOW_IMPORT* und TABIM_UPG.

die Empfehlung der SAP widerspricht sich hier an zwei Stellen. In SAP Note 1616401 sagt die SAP, man solle für die Anzahl der R3trans Prozesse die Anzahl an CPU-Kernen (erkannt durch die ST06) für die Anzahl der R3trans Prozesse nehmen. In SAP Note 2643221 heißt es, man solle genau wie bei R3load die doppelte Anzahl verwenden, dies sei „ein guter Richtwert“. Aus meiner Sicht handelt es sich hier um einen Formulierungsfehler und die Vorgabe aus 1616401 gilt. Gemäß SAP Note 2643221 bzw. 2691785 (ja ich weiß, diese sind bezogen auf einen bestimmten SUM 1.0 Release) sagt die SAP, dass gemäß ihrer Erfahrungen die Anzahl der R3trans Prozesse nie höher als 40 gesetzt werden. Ein genaueres Sizing über das SUM Benchmark Tool bringt Sie näher an die optimalen Zahlen.

Wenn Sie die Note 1616401 wirklich ausführlich lesen, finden Sie auch einen Verweis zur Note 1597414. Hierbei geht es darum, dass bei bestimmten Systemen die Parallelisierung von R3trans nicht genutzt wird, weil im Quellrelease die tabelle TRBAT3 nicht existiert. Im Endeffekt kann dieses Performanceproblem bei allen Quellsystemen mit einem Kernel unterhalb von 7.40 passieren. Es lohnt sich also, hier möglicherweise zu prüfen. Wo das Problem genau her kommt, erfahren Sie in Note 1127194.

Ausbesserung durch datenbankspezifische Hinweise

Anhand der oben geschilderten Optimierungen haben Sie nun bereits grobe Werte für die vier Prozessparameter festgelegt. Bevor Sie diese jedoch nun „einloggen“ und in die Felder des Software Update Manager eingeben, sollten Sie noch die datenbankspezifischen Restriktionen aus SAP Note 1616401 betrachten, je nach Quelldatenbank Ihres Systems. Ich versuche hier, die aktuellen Ausführungen des SAP Hinweises wiederzugeben. Dem Tuning der Datenbankparameter, was auch teilweise in der Note angesprochen wird, widmen wir eine extra Sektion in diesem Beitrag.

Für MS SQL ist im wesentlichen der MaxDOP Parameter entscheidend. In der SAP Note ist eine schöne Grafik, welche das Finden des richtigen Wertes für Sie komfortabel und einfach macht.

Für Oracle werden Sie lediglich dazu aufgefordert, die Parameter gemäß der einschlägigen SAP Hinweise zu konfigurieren. Diese SAP Hinweise nehmen wir uns in einem datenbankorienteirten Kapitel in diesem Beitrag extra zur Brust. Selbiges gilt für SAP ASE, SAP HANA und MaxDB. Für IBM DB2 hingegen gibt es ein extra IBM Dokument im PDF Format. Auch hieraus werde ich Ausschnitte in diesem Beitrag unterbringen.

Memory-optimized activation

Lassen Sie den Menüpunkt unbedingt aus, wenn Sie eine moderne Hardwarearchitektur haben, wählen Sie ihn an, wenn Sie auf 32bit (z. B. IA32 oder klassische Intel x86) unterwegs sind (SAP Note 1630256)

HANA Quellreleases: Verwenden Sie den SUM10HDB*.SAR

Wenn Sie ein HANA Quellrelease haben, lohnt es sich zu prüfen, ob für Ihre Prozedur der optimierte Software Update Manager SUM10HDB unterstützt wird. Dieser ist speziell für HANA-to-HANA Prozeduren optimiert und reduziert die Laufzeiten, auch wenn ich aktuell nicht mit konkreten Zahlen dienen kann.

Verwenden einer aktuellen Version des SUM

Wie schon an anderer Stelle beim Patchen des Kernels erwähnt, sagt der gesunde Menschenverstand eigentlich: Warum sollten wir einen anderen SUM verwenden als den, den uns der Maintenance Planner in den Download Basket gelegt hat? Der wird sich schon was dabei gedacht haben. Außerdem ist ein SUM SP, das schon länger verfügbar ist, besser durch die Gesamtheit der SAP Kunden getestet. Daher sind mehr Probleme mit diesem SUM SP bekannt. Ich habe lange Zeit auch so argumentiert.

Die historische Erfahrung meinerseits hat jedoch gezeigt, dass es viel öfter sinnvoll ist, vor dem Upgrade eine höhere SUM Version zu nehmen, wenn diese für die geplante Prozedur freigegeben ist (muss geprüft werden), als die ursprünglich durch den Maintenance Planner vorgesehene. Fraglich ist nun die Wahl, ob Sie lieber einen höheren Patchlevel für den ursprünglich geplanten SUM SP, oder geich ein höheres SUM SP (falls verfügbar) herunterladen sollen. Im Zweifel würde ich mich, wenn die Veröffentlichungstermine von Patchlevel und SUM SP nahe beieinander liegen, für das höhere Patchlevel des niedrigeren SPs entscheiden. Das ist dann quasi die Kombination aus beiden Argumentationspunkten, also der Kompromiss.

Selbstverständlich sollten Sie innerhalb der Systemlinie immer den selben SUM verwenden, auch wenn im Laufe des Projektes eine neuere Version heraus kommt.

Optimierung des Table Splittings

Unter Table Splitting versteht man die Aufteilung großer Tabellen auf dem SAP System in mehrere Pakete (Packages, auch Buckets genannt). Das heißt, eine Tabelle wird in mehrere Teile „geschnitten“, die durch mehrere R3load Prozesse parallel importiert werden können. Ihr könnt euch das so vorstellen, dass auf der Zieldatenbank SAP HANA Speicherbereiche für eine Tabelle reserviert werden. Nehmen wir an eine Tabelle ist 100 GB groß und sie wird in drei Buckets aufgeteilt. Dann ist es möglich, auf der Zieldatenbank drei Speicherbereiche zu reservieren, die der Einfachheit halber jeweils 33,33 GB groß sind.

Nun können diese drei Buckets durch drei R3load Prozesse parallel in die SAP HANA Datenbank importiert werden. Dabei werden gleichmäßig die drei Speicherbereiche gefüllt. Am Ende der Prozedur, wenn alle drei Speicherbereiche gefüllt sind – werden die drei Tabellenteile in eine große Tabelle zusammengefügt, was nur einen Bruchteil der Zeit braucht, die es für den Import benötigte. So spart man Zeit.

Sie können es aber auch übertreiben. In je mehr Teile Sie eine Tabelle zerteilen, desto langsamer wird die Lesegeschwindigkeit dieser Tabelle. Sie beschleunigen damit also den Import, verlangsamen aber den Export der Tabelle. Und da eine Migration immer aus der paarweisen Integration von Export und Import besteht, ist das nicht gut. Wie immer im Leben müssen Sie also die goldene Mitte finden.

So weit, so gut. Das Table Splitting kommt immer dann zum Einsatz, wenn große Tabellen über R3load exportiert oder importiert werden sollen – de fakot also bei jeder heterogenen Systemkopie und bei einer Database Migration Option (DMO). Durch die Technik des Table Splittings kann man Zeit sparen.

Nun kann es aber sein, dass das Table Splitting nicht sauber durchgeführt wurde. Teilt man eine große Tabelle, die beispielsweise sagen wir einfach mal 500 GB groß ist, nicht auf – müssen die gesamten 500 GB dieser einen Tabelle von einem einzigen R3load-Prozess importiert werden. Das dauert zwar ewig, ist aber OK, wenn das System ohnehin ausgelastet ist mit R3load Prozessen, weil parallel viele andere Buckets importiert werden können. Nicht OK ist es, wenn alle anderen Buckets schon fertig sind, und die Migration nur noch darauf wartet, dass dieser eine R3load Prozess fertig wird. Dann ist nämlich dieser eine R3load Prozess „das schwächste Glied“ in der Kette. Er verlangsamt die gesamte Migration und verlängert dadurch die technische Downtime.

Wie findet man solche „unsauber getrennte Tabellen“? Im Endeffekt agnz einfach. Am Ende eines DMO Benchmarks oder gar am Ende einer probeweisen Migration auf einer Sandbox gibt es die Möglichkeit einen Graphen zu betrachten. Dieser Graph zeigt, wie viele R3load Prozesse zu welchem Zeitpunkt der Migration gelaufen sind. Wenn Sie von Anfang die Anzahl der R3load Prozesse festlegen und im Laufe der Migration nicht mehr ändern, sollte die Anzahl der gleichzeitig laufenden R3load Prozesse bis kurz zum Ende hin konstant bleiben (OK, nicht ganz konstant, weil immer ein paar Prozesse etwas früher fertig werden und danach neue angestartet werden müsen, während anderenoch arbeiten).

Sie haben genau dann ein Problem, wenn gegen Ende der Migration die graphische Visualisierung der R3load Prozesse „einen Schwanz hinterher zieht“. Je länger dieses „Tail“, desto länger musste auf diese paar restlichen R3load Prozesse gewartet werden und desto schlechter ist daher das Table Splitting verlaufen.

Die Anzahl der R3load Prozesse bleibt solange konstant auf einem hohen Level, is die Auslastung der einzelnen R3load Prozesse unter 90% sinkt. Ist dies der Fall, reiht der Software Update Manager die Tabellen nicht in mehrere parallele, sondern seriell in immer weniger R3load Prozesse ein, bis diese nun eine jeweilige Auslastung von 90% aufweisen. Dadurch möchte man die Auslastung der CPU optimieren. Diese Logik kann aber nach hinten los gehen und zeigt sich dann entsprechend in einem solchen Tail.

Wie optimieren Sie nun das Table Splitting so, dass Sie eine optimale Auslastung der R3load Prozesse und damit einhergehend einen optimalen Parallelisierungsgrad der R3load Prozesse erzielen? Unter der Database Migration Option müssen Sie die Buckets nicht selbst definieren. Das einzige, was Sie beeinflussen können und müssen, ist dem SUM beizubringen, dass er die Buckets nicht nur anhand der Tabellengrößen, sondern auch anhand der Laufzeit der Tabellen optimieren soll. Wie bringen Sie das dem Software Update Manager bei? Indem Sie aus einem SUM-Lauf eines Vorgängersystems (oder eines Systems mit ähnlicher Tabellengrößenverteilung) die Dateien SUM\abap\htdoc\MIGRATE_UT_DUR.XML und SUM\abap\htdoc\MIGRATE_DT_DUR.XML aus dem Vorgänger-SUM in den Download-Ordner des neuen SUM kopieren, in welchem sich die Download-Medien befinden. Alternativ können Sie die Dateien in einen beliebigen Ordner kopieren, auf welchen der <sid>adm Leserechte hat, und dem neuen SUM in der SAPup_add.par über den Parameter /clonepar/clonedurations übergeben. Nun analysiert der SUM bei der Definition der Buckets die Laufzeiten aus diesen Dateien und verbessert dadurch sein Table Splitting.

Wenn wir schon bei der SAPup_add.par sind, können Sie auch gleich noch den Paramter /ORA/update_spacestat setzen, den ich an anderer Stelle erkläre. Die folgenden Paramter müssen Sie in der Datei nur setzen, wenn Ihr R3load des Quellkernels nicht die 7.42er Version aus SAP Note 2118195 – R3load aborts during unicode conversion and declustering erzielt (Kernel 7.42 64 Bit Patch Level 35 oder höher). In der Downtime wird ja schon der neue Kernel verwendet – aber wenn Sie die Parameter auch schon für Ihren 7.20er R3load im Quellkernel setzen, profitert davon die Kopie des Repositorys beim Aufbau der Schatteninstanz.

/clonepar/imp/procenv = HDB_MASSIMPORT=YES # setzen Sie diesen PArameter zusätzlich als Umgebungsvariable auf Betriebssystem-Ebene
/clonepar/indexcreation = after_load
/clonepar/clonedurations = <absolute_path>/MIGRATE_UT_DUR.LST,

Wie die SUM Logik zum Table Splitting genau funktioniert, erfahren Sie in diesem Blog Post der SAP.

was ist nun mit der Systemkopie? Bei einer klassischen SWPM Systemkopie können Sie manuell ein eigenes Table Splitting konfigurieren. Ob das wirklich beser ist als die SUM Logik, ist fraglich. Sie könnten beispielsweise erwägen, statt einer Systemkopie eine DMO without Upgrade zu machen – eine Prozedur, die der SUM mittlerweile anbietet – um vom automatischen Table Splitting zu profitieren.

Wenn Sie hingegen manuell splitten wollen, können Sie zunächst die Laufzeit der Pakete über den Time Analyzer auslesen (SAP note 784118) und danach ein manuelles Splitting vornehmen.

Table Comparison

Der Software Update Manager bietet Ihnen die Möglichkeit, nach Abschluss des Shadow Imports einen kompletten prüfsummenbasierten Vergleich der Tabelleninhalte von Quell- und Zieldatenbank zu vergleichen. Dies bedeutet, dass er sämtliche Datensätze sowohl auf der Quell- als auch auf der Zieldatenbank lesen muss, wenn Sie im Software Update Manager auswählen „Compare content of all tables (target vs. source DB). Dies führt im Endeffekt dazu, dass Sie die Migrationszeit verdoppeln.

Grundsätzlich ist das Feature zum Vergleichen von Tabellen sinnvoll. Schließlich wollen Sie sicherstellen, dass die Daten erfolgreich und konsistent migriert wurden. Jedoch gibt es folgendes zu beachten:

• Auch wenn Sie die Table Comparison komplett ausschalten, prüft der Software Update Manager zumindest der Anzahl an Zeilen in allen Tabellen, er macht also im Prinzip ein select count(spalte) auf die Tabellen. Die Anzahl der Datensätze mus also so oder so gleich sein
• Sie haben die Möglichkeit, die prüfsummenbasierte Vergleichsmethode auf geschäftskritische Tabellen, insbesondere aus dem FI-Bereich, einzugrenzen. Dadurch stellen Sie sicher, dass der Vergleich nicht auf unkritischen Tabellen ausgeführt wird, und sparen jede Menge Zeit
• wirtschaftsprüfungsrelevante Konsistenzprüfungen können Sie auch Prüfung der Konsistenzen durch die FI-relevanten Transaktionen selbst steuern. Eine Liste finden Sie beispielsweise in diesem Bietrag von mir.

Als Kompromiss können Sie eine Full Table Comparison gerne auf einer Kopie des Produktivsystems (auf einer Sandbox oder dem Q System beispielsweise) durchführen. Wenn die Full Table Comparison auf der Sandbox keine CRC-Fehler wirft, ist die Wahrscheinlichkeit, dass bei gleicher Parametrisierung die Prüfsummen der Tabellen in der Produktion gleich sind, hoch.

Systemkopie: Verwenden des Distribution Monitors (DistMon)

Nur für die Systemkopie, nicht für die DMO verfügbar ist die Möglichkeit des Einsatz des Distribution Monitors. Der DistMon kann auf fremden Systemen installiert werden, um zusätzliche Verarbeitungskapazität für R3load-Prozesse bereitzustellen. Das heißt wenn Ihr SAP Anwendungssserver, auf welchem der R3load

Optimierung der Near-Zero Downtime Maintenance (nZDM)

Für die nZDM Version des JavaStacks gibt es mitunter eine zu implementierende Note
2021818 – nZDM Java: Performance improvements

Optimierung der SLT basierenden Replikation der Near Zero Downtime Technologie (NZDT)

Wenn Sie vom Service der NZDT Gebrauch machen, können Sie die Performance der SLT Replikation an bestimmten Stellen verbessern. Erster Schritt ist immer die Prüfung relevanter Performance-Notes für das DMIS addon, historische Beispiele sind etwa 1946402 – NZDT: Poor performance for logging table access in case of DB2/zOS source system und 1988330 – NZDT: Performance issues in logging table creation

DaFRK

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

https://www.andreas-loibl.eu

Der Beitrag Optimierung der Conversion / Migration Performance erschien zuerst auf DaFRK - Online Brainware for IT Professionals.

In diesem Beitrag liefere ich einen kurzen Überblick über die verschiedenen Downtime-optimierten Approaches des Software Update Manager, die Szenarien in welchen sie eingesetzt werden können und wie sie funktionieren.

SUM DMO, ZDO, nZDM und NZDT Overview

Die folgende Tabelle zeigt zunächst die verschiedenen Herangehensweisen, die Upgrade-Szenarien, für welche sie verfügbar sind, die Verfügbarkeit und die zentrale SAP Note dazu.

Grundlegende Funktionsweise der SUM Schatteninstanz

Bereits die gewöhnliche Upgrade-Funktionalität des Software Update Managers besitzt die Fähigkeit, die Downtime eines Upgrades zu funktionieren. Damit wir die Benefits der anderen Approaches verstehen, ist es notwendig, die Funktionalität der Schatteninstanz im Ansatz zu verstehen.

Wenn Sie ein Upgrade ohne Schatteninstanz durchführen, bedeutet das eine längere Downtime. Denn ohne Schatteninstanz müssen alle Anteile des Upgrades auf den produktiven Tabellen erfolgen. Ich verusche die Erklärung zunächst über den Ansatz aus diesem offiziellen SAP Blog.

Ohne Schatteninstanz müssen die Renovierungsarbeiten in dem selben Haus durchgeführt werden, in dem Sie wohnen.

Wenn Sie sich hingegen für den Aufbau einer Schatteninstanz entscheiden, bauen Sie vor den eigentlichen Renovierungsarbeiten ein zweites Haus auf, während Sie immer noch in Ihrem aktuellen Haus wohnen bleiben.

Unrealistisches Szenario, sagen Sie? Nun, der Aufbau eines zweiten Hauses könnte Sie tatsächlich teurer kommen, also einfach mal für ein paar Monate bei den Eltern einzuziehen, das gebe ich zu. Gott sei Dank bezieht sich unsere Analogie aber auf ein digitales Szenario. Hierbei kopiert der Software Update Manager Tabellen und Indizes in der Datenbank. Wenn Sie die Summe der SAP Datenbanken als „Repository“ bezeichnen, kopiert sich der Software Update Manager ein „Shadow Repository zusammen“. Der Software Update Manager kopiert hierzu Tabellen und Indizes. Diese sind häufig daran zu erkennen, dass Sie hinter dem eigentlichen Namen der Original-Tabelle ein Suffix drangehängt wird (z. B. zwei Tilden ~~ oder der Zusatz .SHD am Ende des Tabellennamens). Diese Kopien sind aber in der selben Datenbank und im selben Datenbankschema wie das Originalsystem, deswegen müssen Sie auch anders heißen, damit es hier nicht zu Namenskonflikten kommen.

Selbstverständlich kostet Sie auch der Aufbau der Schatteninstanz etwas. Zum einen benötigt es einige Zeit, bis das zweite Haus gebaut ist. genau so benötigt es auch einige Zeit, bis die Schatteninstanz durch Kopien der Original-Tabellen aufgebaut ist. In erster Instanz verlängert der Aufbau Ihres Schatten-Hauses bzw. Ihrer Schatteninstanz also erst einmal die Zeit der Renovierung bzw. der Migration.

Ein weiteres Problem ist, dass der Aufbau Ihres Schattenhauses Sie nicht nur Zeit kostet, sondern auch Ressourceneinsatz (in Form von Ziegeln, Beton usw.) und damit Geld. Bei der Schatteninstanz „zahlen“ Sie diese Ressourcen in der Form der technischen Systemressourcen. Denn das System muss jetzt zusätzlich zur produktiv genutzten SAP Instanz zusätzlich eine Schatteninstanz betreuen. Das beeinträchtigt ein wenig die Performance – jedoch ist dies in der Praxis häufig nicht oder nur zu Spitzenzeiten für den Anwender spürbar. Nachdem das Schattenrepository nämlich aufgebaut ist, können Sie sch an der Schatteninstanz anmelden. Im SAP Logon geben Sie dazu die selbe System-ID, aber eine andere Instanznumer ein.

Wie Sie sehen, ist die sogenannte Schatteninstanz nicht gleichzusetzen mit einer klassischen „Dialoginstanz“. Denn wenn Sie mehrere Dialoginstanzen eines Systems haben, greifen diese trotzdem immer auf die gleichen Tabellen, also auf das gleiche Repository, zu.

die Schatteninstanz hingegen greift explizit auf die Schattentabellen im Schatten-Repository zu, ist also logisch vom Original-Repository abgetrennt. Ein zweites Haus eben, welches auf einem vollkommen anderen Fundament steht. Das Schattenrepository installiert zunächst die Standard DDIC-Objekte des Zielreleases aus dem sogenannten „Upgrade Export“ und überführt dort im Anschluss (durch Zauberei mit Hilfe der SPDD) die kundeneigenen Veränderungen an diesen Standard DDIC Objekten. Des Weiteren werden kundeneigene DDIC Objekte im Kundennamensraum überführt. Nun haben Sie ein komplettes Schatten-Repositorys Ihres Quellsystems, nur halt eben im Zielrelease, so weit wie der Upgrade Export dies möglich macht. Es kann notwendig sein, dass im Anschluss daran noch über R3trans diverse Pakete importiert werden. Das sind dann quasi alle Support Packages, die nicht im Upgrade Export enthalten waren.

So, anstatt nun die Renovierung auf Ihrem Original-Haus durchzuführen, führen Sie die Renovierungsarbeiten auf Ihrem Schatten-Haus durch. Sie haben initial Zeit und Ressourcen investiert, dieses zweite Haus aufzubauen, profitieren jetzt aber von dem Vorteil, dass Sie so lange in Ihrem alten Haus weiter wohnen können, bis die eigentlichen Renovierungsarbeiten am Schattenhaus abgeschlossen wurden. Der einzige Zeitraum, in welchem Sie nun „wohnungslos“ sind, ist der verhältnismäßig kurze Zeitraum des Umzuges, in welchem Sie Ihre Möbel und Habseligkeiten vom alten in das neue Haus verschieben. Die Abbildung illustriert das.

Sie haben außerdem einen weiteren Vorteil gewonnen: Wenn Ihnen das neue Haus nicht gefällt, können Sie sehr einfach auf den Ursprungszustandes Ihres Originalhauses zurückwechseln, indem Sie wieder zurück in das alte Haus umziehen. Natürlich nur, solange sie es noch nicht eingerissen haben.

Genau die gleichen Vorteile gewinnen Sie bei der Schatteninstanz im Software Update Manager. Dadurch, dass das Upgrade zunächst nur über die Schatteninstanz durchgeführt wird, können Sie bis zu einem gewissen Punkt jederzeit zurück gehen, ohne ein Backup machen zu müssen. Der einzige Unterschied beim Software Update Manager ist der, dass Sie grundsätzlich nicht mehr ohne ein Backup zurück können, sobald Sie in die Downtime gegangen sind, also in dem Moment, an dem Sie ausziehen. Grund: Die Datenstruktur hat sich möglicherwiese geändert. Das wäre ungefähr so, als hätten Sie für Ihr neues Haus die Couch und die Küchengarnitur ein bisschen zuschneiden müssen, damit sie in die neuen Raummaße hinein passen.

near-Zero Downtime Maintenace (nZDM)

Wie funktioniert nun die near-Zero Downtime Maintenance im Verlgeich zu unserem obigen Beispiel? Bei der near-Zero Downtime Maintennace ist der „Umzug der Möbel“, also im technischen Jargon der „Shadow Import“, in der Uptime, sprich im Live-Betrieb möglich. Wie dürfen wir uns das vorstellen? Nun, das wäre ungefähr so, als wenn Sie während der Renovierungsarbeiten Änderungen an Ihren Möbeln im Original-Haus vornehmen würden (Neue Möbel hinzufügen, Möbel entsorgen, Möbel zuschneiden und umstellen) und diese Änderungen gleichzeitig im Schattenhaus repliziert werden würden. Das heißt, in Ihrem alten Haus schaut ständig jemand zu, was Sie gerade machen, und ruft beim Handwerker im Schattenhaus aus, um ihm zu sagen, was er ändern soll.

Vorteil der ganzen Sache: Weil die von Ihnen gewünschten Möbel schon im neuen Haus drin sind, müssen Sie eigentlich nur noch sich selbst in das neue Haus verfrachten (alles Andere ist ja schon da) und Ihre Adresse ändern. Genau so muss es auch unser SAP System tun. Das System muss jetzt am Ende nur noch die Tabellen umbenennen, und Sie als User müssen sich danach im neuen System einloggen.

Jetzt werden Sie mir aber sagen: „Andreas, du spinnst ja.“ Wenn ein Handwerker dem anderen sagt, er soll das und das machen, sieht das doch unmöglich so aus, wie beim ersten Handwerker. Die beiden arbeiten ja ganz unterschiedlich, und wenn die nur eine Schraube oder einen Dübel anders setzen, sieht die Couch im Schattenhaus doch ganz anders aus als die im Originalhaus. Genau das war der Grund, warum im klassischen Upgrade-Verfahren diese Replikation nicht implementiert und die Downtime länger war. Hat sich im SAP System beispielsweise das Datenmodell geändert, ist das gleichzusetzen mit zwei unterschiedlichen Handwerkern.

Jetzt gibt es aber im digitalen Umfeld die Möglichkeit, Änderungen „aufzunehmen“. Das heißt die Schritte, die der erste Handwerker durchgeführt hat, werden haargenau aufgezeichnet und danach 1:1 repliziert.Im Endeffekt ersetzen wir unsere fehlerbehafteten Handwerk durch eine Produktionsstraße bestehend aus CNC-Fräse und Montagroboter, die genau das machen, was man ihnen vorher einprogrammiert hat. nZDM nennt dies „Record & Replay“. Wenn wir jetzt von unserer einfachen Skizze weg gehen und etwas technischer werden, sieht das Ganze so aus

Funktionsweise des nZDM Change Recordings

Kernbestandteil der near-Zero Downtime Maintenance ist das osgenannte Change Recording bzw. die Record & Replay Technique. Wie bei einem gewöhnlichen Upgrade mit optimierter Downtimephase wird eine Schatteninstanz aufgebaut.

Änderungen, beispielsweise an Bewegungsdaten, werden aufgezeichnet und vom Software Update Manager in einem Change Recorder festgehalten. In der Schatteninstanz werden die Änderungen dann im neuen Datenmodell wiederholt. Man kann sich das so vorstellen, als würde die Transaktion komplett neu aufgerufen und die zu übertragenen Werte neu in den Transkationsbildschirm eingegeben werden. Daher spielt das Datenmodell im Zielrelease eine untergeordnete Rolle.

Sie können die Datenübertragung auf der Schatteninstanz über die Transkation CRR_CONTROL kontrollieren, pausieren und starten. Sie können sogar, um die Migrationszeit weiter zu reduzieren, bewusst Tabellen von der Datenreplikation ausschließen. Dies führt freilich die Dateninkonsistenzen im Vergleich zum Ursprungssystem, die Sie bewusst in Kauf nehmen müssen.

In der ursprünglichen Implementierung der Record & Replay Technik war das System zwar beinahe die ganze Upgrade-Prozedur lang online, dafür hat das Übertragen von sehr großen Tabellen mit zahlreichen Änderungen mehrere Tage und teilweise Wochen gedauert. Diese Zeiten verringern sich drastisch beim Einsatz einer bestimmten dbsl Version. Hierzu muss allerdings auf dem Quellsystem folgender Kernel enthalten sein:

• Kernel 7.45 PL 725
• Kernel 7.49 PL 513
• Patches für neuere Kernel, etwa den 7.53er, sind aktuell in der Entwicklung. Der aktuelle Stand der Patches wir din SAP Note 2591334 bekannt gegeben.

explizit nicht unterstützte Szenarien

Explizit nicht unterstützte Szenarien für near-Zero Downtime Maintenance (nZDM) sind:

• ein Upgrade in Verbindung mit einer Unicode Conversion (Combined Upgrade and Unicode Conversion, CUUC) – SAP Note 928729.
• jegliches Update / Upgrade in einem Quellsystem mit DB2 for LUW Datenbank, wenn das database partitioning feature (DPF) genutzt wird.

Database Migration Option (DMO)

Bewegen wir uns nun einmal weg vom klassischen System Upgrade und nehmen wir die Databse Migration Option (DMO) unter die Lupe. Eine DMO kombiniert eine heterogene Systemkopie (also eine Migration) von einer beliebigen AnyDB nach SAP HANA (oder alternativ für bestimmte Releases nach SAP ASE) und gleichzeitig ein Upgrade. Unter bestimmten Voraussetzungen kann zusätzlich zur Migration und zum Upgrade auch noch zeitgleich eine Unicode Conversion von statten gehen (aber nur wenn der Zielkernel 7.40 ist, für 7.50 geht das leider nicht). Mehr dazu in meinem Beitrag zum Thema Unicode Conversion.

Grob skizziert sieht eine Database Migration Option folgendermaßen aus.

Wie funktioniert die DMO jetzt im Vergleich zum weiter oben kennen gelernten klassischen Upgrade-Prozedere mit Schatteninstanz? Bis kurz vor der Downtime läuft alles gleich. Die Schatteninstanz wird zunächst ganz normal auf der Quelldatenbank (in unserem Fall also auf der Oracle 12 Datenbank) im selben Datenbankschema aufgebaut.

Gleichzeitig wird allerdings noch während der Uptime das Schattenrepository von der Quelldatenbank (unserer Oracle 12) auf die Zieldatenbank kopiert (auf die HANA Datenbank). Dieses Kopieren geschieht über R3load. Das R3load des Oracle-Zielkernels exportiert, das R3load des HANA-Zielkernels importiert. Das heißt, das Schatten-Repository ist nun einmal auf der Quelldatenbank und einmal auf der Zieldatenbank vorhanden.

Das Schattenrepository, und somit alle DDIC Objekte aus dem Upgrade Export im Zielrelease – inklusive der Anpassungen durch die SPDD, sind nun bereits auf der HANA Datenbank vorhanden. Sie haben aktuell also einen fast nackten Zielrelease auf Ihrer HANA (in unserem Beispiel einen fast nackten SAP BW 7.5), mit einigen kundeneigenen Anpassungen in den Repository Objekten. Sie haben nun, wie bei einem normalen Upgrade, noch die Downtime-Phase vor sich, in welcher der Shadow Import durchgeführt wird. Bevor dieser Shadow Import beginnt, schwenkt das SAP System die Datenbankverbindung um auf die HANA Datenbank – die Schatteninstanz existiert zu diesem Zeitpunkt schon nicht mehr.

Sie haben vielleicht schon richtig erkannt, dass wenn nun vor dem Shadow Import schon der Schwenk auf die HANA Datenbank passiert, der Shadow Import auf der Oracle Datenbank gar nicht erst durchgeführt wird. Und Sie haben Recht. Deswegen können Sie im Fall der Fälle, wenn das Upgrade fehl, einfach den NetWeaver Kernel und dessen Profildateien von vor der Downtime zurückkopieren und zurück auf die alte Datenbank (Oracle) schwenken. Dann haben Sie automatisch wieder den Stand von vor der Downtime drin, ohne dass Sie ein Backup in der Datenbank einspielen mussten. Das heißt auch der Fallback auf den alten Release funktioniert schneller als bei der klassischen Vorgehensweise. Zwar haben Sie noch die Schattentabellen das Schatten-Repositorys in der Datenbank, die kriegen Sie aber über einen Reset des SUM wieder raus.

Wenn nun die Downtime einsetzt, wir der eigentliche Shadow Import auf der HANA Datenbank durchgeführt. Der Software Update Manager überträgt die Daten und Pakete per R3load bzw. R3trans direkt an die HANA Datenbank und führt währenddessen gleichzeitig die Konvertierung der Quelldaten vom Oracle-Quellformat in das HANA-Zielformat durch. Zum Schluss geschieht das gleiche wie beim normalen Upgrade auch: Das Shadow Repository wird umbenannt, der NetWeaver Kernel wird ausgetauscht, und das System startet im neuen Zielrelease.

Was ist jetzt der Vorteil von der DMO, ist die Downtime des Upgrades schneller? Nein, das ist wichtig zu verstehen. Die Downtime des Upgrade auf das Zielrelease ist wahrscheinlich länger als bei einem Single System Upgrade, weil Sie die Daten der Downtime nun über das Netzwerk an einen externen Host (in unserem Fall Server 2) übertragen müssen.

Der Vorteil der DMO ist, dass Sie nur eine einzige Downtime haben, weil Sie nämlich das Release Upgrade und die (davor oder danach erfolgende) Systemkopie vereinen. Ansonsten bräuchten sie nämlich eine zweite Business Downtime für die Systemkopie. Wenn Sie sogar noch eine Unicode Conversion kombinieren, sparen Sie hier noch einmal ein wenig Business Downtime.

Downtime-optimized Database Migration Option (DMO)

So, jetzt kommen wir zum ersten mal an eine Stelle, an der ich relativ wenig über eine Herangehensweise des Software Update Managers sagen kann, denn dieser Approach ist derzeit in der Pilotphase und ist daher grundsätzlich erst einmal nur auf Anfrage mit der SAP selbst durchführbar. Sie müssen sich dazu als Kunde mit Ihrem Projekt bewerben. Die Details dazu entnehmen Sie der Not 2442926 – Prerequisites and Restrictions of downtime-optimized DMO .

Jedoch kann ich persönlich eine Vermutung äußern. Meiner Ansicht nach kombiniert die downtime-optimized DMO höchstwahrscheinlich den Ansatz der DMO mit dem Change Recording der near-zero Downtime Maintenance (nZDM). Die technische Umsetzung scheint jedoch auf einer trigger-basierten Replikation zu basieren, wie Sie auch beim SLT zum Einsatz kommt. Dazu habe ich in der Vergangenheit hier schon einmal etwas geschrieben. Das heißt Sie kombinieren im Endeffekt die beiden Ansätze. Das wird im Endeffekt die Magie hinter der ganzen Sache sein, was im Endeffekt bedeutet, dass Sie während des Shadow Imports Datenbewegungen sowohl auf Ihrer Oracle- als auch auf der HANA-Datenbank haben.

Dieses Szenario ist nur freigegeben für die beiden Produkte SAP ECC 6.0 und höher und SAP CRM 7.0 und höher, und Sie können die downtime-optimized DMO nicht verwenden, wenn Sie zusammen mit der DMO den Application Server auf einen anderen Host umziehen wollen (das können Sie jedoch natürlich nachträglich machen, indem Sie eine Instanz über den SWPM nachinstallieren).

Da die Option derzeit in einer Pilotphase steckt, wissen wir noch nicht, ob sie irgendwann Generally Available (GA) sein wird. Meiner Meinung nach ist dies jedoch sehr wahrscheinlich.

klassische S/4HANA System Conversion

Die klasse S/4HANA System Conversion gibt es auf zwei Arten. Mit Database Migration Option (wenn das Quellsystem noch auf AnyDB läuft und noch nicht auf SAP HANA) oder ohne DMO (wenn das Quellsystem bereits auf SAP HANA läuft). Im Endeffekt heißt das

• wenn Ihr Quellsystem auf AnyDB ist, machen Sie eine DMO (da der Zielkernel unter S/4 aber >=7.50 ist, können Sie in der DMO keine Unicode Conversion mit machen)
• wenn Ihr Quellsystem auf HANA ist, machen Sie ein klassisches Upgrade (wie ganz oben als erstes skizziert)

Mit einem feinen Unterschied. Die Phasen des Software Update Managers sind bei einer S/4HANA System Conversion größtenteils gleich im Vergleich zu einem klassischen Business Suite Upgrade. Im Gegensatz zu einem klassischen Business Suite Upgrade kommt bei einer S/4HANA System Conversion jedoch eine Datenkonvertierung im Postprocessing dazu. Mindestens für die Bereiche FI/CO (das ist der Schwenk auf das Universal Journal – ACDOCA) und für den Material Ledger (das ist der Switch auf die MLDOC). Informationen über die Hintergründe finden Sie in meinem Beitrag zum Universal Journal.

Ein Teil dieser Datenkonvertierung geschieht während der technischen Downtime, ein Teil als Nacharbeit während der technischen Uptime (jedoch immer noch während der Business Downtime, da Sie vor abgeschlossener Konvertierung das System nicht freigeben dürfen). Und einen nicht unerheblichen Teil müssen Sie in Form von Vorarbeiten vorbereiten, sonst funktioniert das Ganze sowieso nicht.

Downtime-optimized Conversion

Wie schon die Downtime-optimized DMO ist auch die Downtime-optimized Conversion ein Pilotprojekt der SAP. Auch hier müssen Sie sich mit Ihrem Projekt zuerst bewerben. Mehr dazu erfahren Sie in der SAP Note
2293733 – Prerequisites and Restrictions of downtime-optimized conversion to SAP S/4HANA. Meine Vermutung ist, dass es sich hier im Endeffekt um eine S/4HANA System Conversion in Verbindung mit einer downtime-optimized DMO handelt. Erneut werden hier also bereits gegebene Strukturen miteinander verknüpft.

Zero Downtime Option (ZDO)

Auch die ZDO ist derzeit nicht Generally Available, sondern nur über einen Piloten in Zusammenarbeit mit der SAP verfügbar. Für Restriktionen und Informationen zur Anmeldung konsultieren Sie SAP Note 2707731. Die Zero Downtime Option heißt Zero Downtime Option, weil es keine technische Downtime gibt. Eine Business Downtime, in welcher das System isoliert, nachbearbeitet und getestet werden muss, gibt es allerdings immer noch.

Die Zero Downtime Option funktioniert ganz anders als wir es bisher kennen gelernt haben. Ich erkläre es wieder mit unserer bisherigen Analoge. Anstatt unser Haus zu klonen und auf dem Klon die Renovierungsarbeiten durchzuführen, erstellen wir stattdessen einen minimalen Klon unseres Hauses (auf dem nur die notwendigsten Räume existieren, also z. B. Wohnzimmer, Küche, Schlafzimmer und Bad. Die restlichen Räume werden „nicht kopiert). Und während in unserem Original-Haus die eigentlichen Wartungsarbeiten durchgeführt werden, ziehen wir in unser „Mini-Haus“ um und wohnen derweil dort.

Und genau das passiert bei der Zero Downtime Option. Anstatt das Original-Repository vollständig in ein Shadow Repository zu klonen und auf dem Shadow Repository das Update durchzuführen, werden nur die wichtigsten Tabellen in ein komplett neues Datenbankschema kopiert. Auf diesem zweiten Datenbankschema (genannt „Bridge“) sind alle Tabellen, die gebraucht werden, um die wichtigsten Business- und Schnittstellen-Funktionalitäten zu halten. Ab dem Punkt, wo auf dem Original-Datenbankschema die Downtime initiiert wird, werden die User (ohne es zu merken) auf das kopierte Schatten-Datenbankschema umgeleitet und arbeiten auf diesem weiter.

Am Ende der Downtime auf dem Haupt-Datenbankschema werden die erzeugten Daten auf der Bridge dort hin übertragen, und die User arbeiten irgendwann wieder (ohne es wirklich zu merken) auf dem ursprünglichen Schema.

Aufgrund dieser technischen Funktionsweise der ZDO ist diese jedoch nicht für alle Upgrade-Vorhaben verfügbar. Ein Quellrelease von SAP S/4HANA 1709 FPS02 oder höher und eine SAP HANA 2.0 Datenbank mit SPS02 oder höher wird benötigt. Die ZDO wird sehr gerne für SAP S/4HANA Support Package Stack Updates verwendet.

Near-Zero Downtime Technology (NZDT) bzw. Minimzed Downtime Service (MDS)

Bei diesem Approach handelt es sich um ein Paket aus Beratungsdienstleistungen der SAP, welche für zahlreiche Upgrades verwendet werden knnen. Hierbei bekommen Sie im Endeffekt ein Paket, dessen Bestandteil auch die Optimierung der Downtime beinhaltet.

Möglich ist, dass zum einen die weiter oben vorgestellten Approaches angeboten und durch technische Optimierung ergänzt werden, zum anderen aber beispielsweise auch Services wie ein Upgrade mit einem geklonten System angeboten werden könnten. Das heißt das eigentliche Upgrade machen Sie auf einem Klon des Produktivsystems (während dieses wiederum weiterhin produktiv verwendet wird), und nach dem Upgrade holen Sie sich das Delta vom Originalsystem über eine transformationsfähige Replikationstechnologie. Das ist jedoch wieder nur eine Vermutung meinerseits, eine wirkliche Bestätigung bekommen Sie nur vom Hersteller selbst.

DaFRK

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

https://www.andreas-loibl.eu

Der Beitrag SAP Software Update Manager Approaches im Überblick erschien zuerst auf DaFRK - Online Brainware for IT Professionals.

In diesem Beitrag sammele ich die am häufigsten benötigten Vorarbeiten und Überlegungen im Hinblick auf die betriebswirtschaftliche bzw. fachbereichsspezifische Vorbereitung eines SAP ERP Systems vor einer System Conversion. Das bedeutet, dass die hier aufgeführten Änderungen nur die gängigsten darstellen und ein Studium der Simplification List und eine Analyse mit Hilfe der entsprechenden Pre-Checks nicht ersetzen kann. Wir werden uns zunächst mit dem Begriff der Simplification Items und der Simplification List befassen und gehen danach sofort ans Eingemachte.

Was sind Simplifications und die Simplification List?

Simplifications bezeichnen die Zusammenführung von Entitäten und Softwaremodulen, die früher in mehreren Systemen unter verschiedenem Namen geführt wurden, unter S/4HANA – sowie Erweiterungen des Datenmodells. So wurden früher beispielsweise im SAP ERP System die Entitäten des Debitor/Kreditor Paares („Customer/Vendor“) und in SAP CRM der Geschäftspartner („Business Partner“) gepflegt. In SAP S/4HANA sind die Entitäten Customer/Vendor und Business Partner zusammengeführt – zu Einzelheiten kommen wir in diesem Bereich weiter unten im CVI-bezogenen Kapitel

Technisch ist das Ganze so umgesetzt, dass die alten Transaktionen (VA01 usw.) immer noch auf die klassischen Tabellen KNA1, LSA1 usw. zeigen können, die Daten in Wahrheit jedoch vom Business Partner Datenmodell abgerufen und vom Geschäftspartner-Datensatz gelesen werden. Ein verbildlichtes Datenmodell davon zeige ich weiter unten.

Derzeit gibt es ca. 500 dieser sogenannten Simplification Items. Dies bedeutet auch, dass die veschiedenen Transaktionen zusammengelegt wurden. Sie finden einen Überblick über diese Simplifikationen in der sogenannte Simplification List, die Sie hier betrachten können.

Zentraler Treiber dieser Simplifications ist die Implementierung des „Principle of One“. Demnach soll SAP S/4HANA eine einzige Business Lösung für Unternehmen sein, die verteilte Haupt- und Nebensysteme der Vergangenheit (z. B. ein Konstrukt aus SAP ERP, SAP CRM, SAP SRM und SAP EWM in jeweils getrennten Systemen) überflüssig machen soll.

Die wichtigsten Vereinfachungen (Top Simplification List Items) für den Anfang unter S/4HANA sind

• Die Vereinheitlichung des Datenmodells im FI und im Inventory Management Bereich. Siehe hierzu meinen entsprechenden Blog Post.
• die Vereinheitlichung des Datenmodells befreit von der zwangsweisen Speicherung von Redunanzen und Aggregaten („No Aggregates“). Dadurch gibt es beispielsweise keinen Übertrag von Preisen mehr auf der Tabelle MBEW.
• Customer Vendor Integration (CVI), wie oben bereits angesprochen.
• Discrete Industry Mill Products (DIMP) ist wieder im Anwendungskern integriert.
• Erweiterung des Datenelementes „MATNR“ in der Tabelle „MARA“ von 16 auf 40 Zeichen (Lange Materialnummer „LAMA“).
• Die Embedded BW Funktionalität deckt viele Standard-Einsatzszenarien von Business Warehouse bereits im S/4HANA Kern ab, ohne die Notwendigkeit von ETL.
• Replacement bzw. Konsolidierung operationeller Informationsssysteme, wie etwa des Logistics Information System (LIS), in die Analysemöglichkeiten von SAP HANA (SAP HANA Views, Operational Data Store ODS)
• Integration von SAP Enterprise Warehouse Management (SAP EWM) in den S/4HANA Core
• Integration grundlegender SAP Global Trade Services (GTS) Funktionalitäten in die Foreign Trade Komponente (SD-FT) von S/4HANA.
  Die wichtigsten Simplification Items werden zusätzlich in diesem Blogpost gesammelt.
• Die Notwendigkeit der Nutzung eines externen Advanced planning and Optimization (APO) Systems für die detaillierte Produktionsplanung entfällt unter S/4HANA. Sie geht in die integrierte PP/DS Komponente von S/4 in den Standard über.

Line of Business Vorbereitungen in Business Uptime

Soweit möglich, sollten Sie die Line of Business Vorbereitungen vor den technischen Vorbereitungen durchführen. Zumindest, bevor Sie die S/4HANA Readiness Checks und andere vorbereitende Checks durchführen. Denn wenn Sie die Vorbereitungen schon jetzt durchführen, haben Sie später bei den Checks weniger Findings, die Sie vor der eigentlichen System Conversion auflösen müssen.

Customer Vendor Integration (CVI)

Schon seit einiger Zeit bietet die SAP die Logik des Geschäftspartners (Business Partner) an. In der klassischen getrennten Datenhaltung von Kreditoren und Debitoren gab es einige datenhalterische Limitierungen

• nur eine Adresse pro Geschäftspartner
• keine Beziehung zwischen Objekten möglich, diese mussten stattdessen als getrennte Entitäten gepflegt werden.
• Keine Personen pflegbar

Mit dem Datenmodell des Geschäftspartners werden diese Einschränkungen umgangen. Nicht nur ist es nun möglich, die selben Stammdaten sowohl für die Kreditoren- als auch die Debitoren-Sicht zu verwenden, es können nun mehrere Geschäftspartnerkategorien gepflegt werden – von der Organisation und der Person bis hin zu Gruppierungen. Ein Geschäftspartner kann sowohl als Debitor als auch als Kreditor auftreten und dabei mehrere Adressen, Zahlungsdaten und Beziehungen im Bauch haben, die in zeitlichem Kontext Anwendung finden können.

Auch sind nun Beziehungen zwischen Geschäftspartner Entitäten möglich. „Person X ist Kontaktperson für Organisation Y. Organisation Y ist Service Provider für Organisation Z etc.“ Das Geschäftspartnerkonzept ist bereits unter SAP ECC 6.0 nutzbar. Es wird unter ECC u. A. genutzt in den Bereichen

• SAP Collections Management (FSCM-COL)
• SAP Credit Management (FSCM-CR)
• SAP Treasury and Risk Management (TRM)
• Loans Management (FS-CML)
• sowie in weiteren strategischen Produkten der SAP, darunter CRM, SCRM, SRM und GTS.

Neu an der Customer Vendor Integration ist im Endeffekt, dass die Geschäftspartnerlogik in die Objekte Debitor und Kredit integriert wird. Das heißt die alten, klassischen ECC Transaktionen der kreditorischen und debitorischen Buchhaltung, z. B. die VA01, zeigen mitunter weiterhin auf die Tabellen aus der klassischen Customer/Vendor Logik (z. B. KNA1, LFA1), diese holen sich die Daten aber aus den eigentlichen Master Stammdaten aus der Geschäftspartnerlogik.

Leider können nicht alle Daten redundanzfrei nur in der Geschäftspartnerlogik gespeichert werden. Einige Daten sind redundant vorgehalten, damit Nebensysteme, die noch mit der alten Customer/Vendor Logik arbeiten, kompatibel sind. Stattdessen werden die Daten über Linker Tabellen miteinander in Beziehung gesetzt. Geschäftslogik sorgt hierbei dafür, dass bei der Änderung eines klassischen Customer/Vendor Datensatzes der entsprechende Geschäftspartner Eintrag mit betroffen ist.

Die Verteilung von Business Partner Objekten an Nebensysteme kann über ALE/IDOCS geschehen. Die hierzu notwendige Logik kann über das Data Replication Framework (DRF) implementiert werden.

Dadurch erreichen Sie, dass Sie die Daten nun nur noch an einer Stelle, nämlich im Geschäftspartnerobjekt, pflegen – und trotzdem alle Softwarefunktionalitäten mit ihrer bisherigen Logik weiter funktionieren. Erst dadurch wird es möglich, dass diverse strategische Produkte der SAP in den S4CORE integriert werden. Zentrale Fragen über die Customer Vendor Integration werden in SAP Hinweis
2713963 beantwortet.

Nur mit implementierter Customer/Vendor Integration ist es einem Business Suite Quellsystem möglich, eine Konvertierung nach S/4HANA Enterprise Management zu erfahren. Für das Simple Finance 2.0 Addon (mittlerweile von der SAP nicht mehr empfohlen – gehen Sie direkt auf S/4HANA Finance oder S/4HANA Enterprise Management) oder eine Migration auf S/4HANA Finance ist die Implementierung der CVI NICHT notwendig. Alle Debitoren und Kreditoren müssen in diese Logik migriert sein. Zentraler Einstiegspunkt für die Geschäftspartnerpflege ist die Transaktion BP.

Unter S/4HANA läuft es dann so, dass alle bisherigen ECC Transaktionen, Reports, Formulare etc., die entweder Kreditoren oder Debitoren als Eingabeobjekt angenommen haben, auch weiterhin eine Debitor- bzw. Kreditor-Nummer erwarten – egal ob diese bereits zu einem Geschäftspartner verbunden wurden und die selbe Nummer tragen, oder unterschiedliche Nummern. Sie geben also die Nummer des Kreditoren/Debitoren an, NICHT die Nummer des Geschäftspartners. Der Vendor heißt im englischsprachigen Raum unter S/4 auch nicht mehr Vendor, sondern Supplier.

Es wird Ihnen aus Usability Gründen explizit empfohlen, die Geschäftspartnernummer identisch mit der entsprechenden Kreditoren- bzw. Debitoren-Nummer zu wählen. Um außerdem nicht all zu viele Datensätze konvertieren zu müssen, sollten Sie nicht mehr benötigte Customer/Vendor Sätze mit dem Deletion Flag archivieren. Alle nicht archivierten Debitoren und Kreditoren (trotz gesetztem Deletion Flag) MÜSSEN auf die CVI Logik konvertiert werden, bevor Sie Ihre System Conversion beginnen.

Trotzdem ist es so, dass sobald Sie auf CVI umgestellt haben, die folgende Liste an Transaktionen nicht mehr verfügbar sein werden. Dies soll verhindern, dass Sie Customer/Vendor Datensätze verändern oder hinzufügen, anstatt zentral in der Transaktion BP bzw. den zugehörigen Fiori Apps zu pflegen. Es gibt getrennte Fiori Apps für Customer und Supplier, die jedoch im Hintergrund Business Partner Daten ändern. Auch die Prospect to Customer Logik ist möglich. Sie können einen Geschäftspartner mit der Rolle „Prospect“  (Rolle BUP002) erstellen und später seine Rolle zum Kunden ändern (FLCU01).

Kundeneigener Code, welcher die oben benannten, obsoleten Transkationen betrifft, muss nicht umgeschrieben werden. Die Transkationsaufrufe werden unter S/4 automatisch an die Transkation BP weitergeleitet.

Weiterhin möglich werden jedoch Massenbearbeitungsverarbeitung über GUI-Transkationen sein (XD99, XK99 und MASS) sowie in den Fiori Apps (Customer Master Mass Maintenance, Mass Maitnenance, Supplier Master).

Es ist absolut empfehlenswert, dass Sie die Customer Vendor Integration und ihren Impact zuerst auf Basis einer Sandbox mit Produktivdaten austesten, bevor Sie den Schritt in Ihrer regulären Systemlinie durchführen!

Wenn Sie keine System Conversion vor haben, sondern die Daten in ein frisch aufgesetztes Greenfield S/4HANA synchronisieren wollen, müssen Sie diese Daten im Business Partner Zielformat importieren. Das bedeutet, es muss on the fly eine Transformation der Daten geschehen. Diese Transformation können Sie sowohl über die LSMW, über IDOCs, manuell oder über die Data Services des Solution Manager vornehmen. Weitere Informationen für die Migration von Customer/Bendor Identitäten finden Sie in den SAP Hinweisen 2287723, 2417298 und 2221398.

Alternative zum manuellen Approach

In den Unterkapiteln weiter unten zeige ich Ihnen Schritt für Schritt die manuellen Schritte zur Implementierung der Customer/Vendor Integration auf. Alternativ dazu können Sie sich durch die Implementierung von CVI führen lassen. Implementieren Sie hierzu die folgenden SAP Hinweise

• 2336018 – BP S4HANA : Suppress Mandatory BP field groups checks via MDS_LOAD_COCKPIT transaction
• 2345087 – BP_BAP: Missing values in required entry fields cause postin termination in mass processing
• 2344034 – S/4HANA Automation for Master Data Migration

Notes und Business Functions

Wenn ihr ERP System auf dem Release EHP0 – EHP4 ist, müssen Sie zuvor SAP Note 2383051 implementieren.

Weitere SAP Notes, die Sie als Vorarbeit in Ihre Recherche integrieren sollten, sind namentlich

• Note 2216176 – Precheck report from business partner (Report PRECHECK_UPGRADATION_REPORT)
• Note 2211312 – S4TC SAP_APPL Pre-Conversion check for Business Partner
• Note 1623677 – BP_VCI: Check report for checking CVI Customizing (Report CVI_FS_CHECK_CUSTOMIZING)
• Note 974504 – Inconsistencies in link tables of master data sync. (Report ZCUSTOMER_LINK_CHECK_REPORT)
• Note 2399368 – excel upload option in MDS_LOAD_COCKPIT (Erleichtert die Synchronisation von Customer/Vendor Datensätzen in BP Logik per Excel Upload)
• Note 2309153 – Erweiterungen für Customer Daten in BP Logik (z. b. zusätzliche Tabellenfelder)
• Note 2295823 – Erweiterungen für Vendor Daten in BP Logik (z. B. zusätzliche Tabellenfelder)

Danach aktivieren Sie die Business Functions CA_SUPPLIER_SOA und CA_BP_SOA. Die Schalter „VENDOR_SFWS_SC1“ und „VENDOR_SFWS_SC2“ müssen beide aktiv (Global Status „on“) sein, damit Vendor Personen Datensätze mit Business Partner Kontaktpersonen synchronsieirt werden (Siehe SAP Note 1454441 – Development of contact person for vendors).

Synchronisation aktivieren

Als erstes aktivieren Sie über den IMG Pfad Cross-Application Components – Master Data Synchronization – Synchornization Control – Activate PPO Requests for Platform Objects in the Dialog den PPO Request für das BP Synchronisationsobjekt.

Danach stellen Sie im IMG Pfad Cross-Application Components – Master Data Synchronization – Synchronization Control – Activate Synchronization Options sicher, dass die Synchronisation zwischen Customer/Vendor und BP aktiv ist.

Zu guter letzt aktivieren Sie unter Cross-Application Components – General Application Functions – Postprocessing Office – Business PRocesses – Activate Creation of Postprocessing Orders die PPOs.

Nummernzuweisung

Sie müssen nun festlegen, welche Nummer der Geschäftspartner bekommen soll. Die gleiche Nummer wie der Kreditor/Debitor, und falls zutreffend, welche von den beiden? Ein guter Ansatz für die Vorgehensweise ist der S/4 Converison Guide, explizit das Kapitel „Introduce Business Partner Approach (CVI)“.

Die erste zentrale Frage, die Sie sich stellen müssen, ist: Überlappen sich die Nummernkreise für Debitoren und Kreditoren im Quellsystem? Falls nein, können Sie den Nummernkreis für Geschäftspartner genau so definieren wie für Customer/Vendor zusammen. Falls sie sich jedoch überlappen, sollten Sie den Nummernkreis so wählen, dass möglichst viele individuelle Customer/Vendor Identifikationsnummern in diesem enthalten sind.

Zunächst prüfen Sie den Debitoren Nummernkreis über den IMG Pfad Logistics – General – Business Partner – Customers – Control – Define and Assign Customer Number Ranges und den Kreditoren Nummernkreis über den IMG Pfad Logistics – General – Business Partner – Vendor – Control – Define Number Ranges for Vendor Master Records. Den Nummernkreis für die Geschäftspartner konfigurieren Sie dann im IMG Pfad Cross-Application Components – SAP Business Partner – Business Partner – Basic Settings – Number Ranges and Groupings – Define Number Ranges/Define Groupings and Assign Number Ranges.

Der Conversion Report MDS_LOAD_COCKPIT weist während der Konvertierung einer Kontaktpersonin eine Business Partner Person eine interne Business Partner Nummer zu. Der zugehörige Nummernkreis ist  der für das Internal Standard Grouping (Feld Int Std.Grping) Wenn dieser Nummernkreis mit den gewünschten Ziel-Customer/Vendor-Nummernkreisen überlappt, muss dieser Nummernkreis für Kontaktpersonen außerhalb davon definiert werden. Es darf auf keinen Fall vorkommen, dass eine Business Partner Kontaktperson die Nummer eines Business Partners bekommt und damit dessen Nummer überschreibt. Dies kann ansonsten zum Fehler R11124 „Business partner with GUID XXXX does not exist“führen.

Kontogruppen (Account Groups) zu Business Partner Rollen mappen

Business Partner Rollen müssen den einzelnen Kontogruppen (TX OBD4) zugewiesen werden. So sollten Sie beispielsweise die Kontogruppen für Debitorenkonten den Business Partner Rollen für Customer bzw. Debitoren zuweisen (BP Rollen FLCU00 und FLCU01). Dies machen Sie im IMG Pfad Cross-Application Components – Master Data Synchronization – Customer/Vendor Integration – Business Partner Settings – Settings for Customer Integration – Define BP Role for Direction Customer to BP.

Umgekehrt sollten Sie den Business Partner Rollen für Vendors bzw. Kreditoren (FLVN00 und FLVN01) der Kontogruppe für Kreditorenkonten zuweisen. Dies tun Sie im IMG Pfad Cross-Application Components – Master Data Synchronization – Customer/Vendor INtegration – Business Partner Settings – settings for Vendor Integration – Define BP Role for Direction Vendor to BP.

Außerdem muss für jede Kontogruppe eine Nummernzuweisung existieren. Für Customer konfigurieren Sie dies im IMG Pfad Cross-Application Components – Master Data Synchronization – Customer/Vendor Integration – Business Partner Settings – settings for Customer Integration – Field Assignment for CustomerIntegration – Assign Keys – Define Number Assignment for Direction Customer to BP. Für Vendors lautet der Pfad Cross-Application Components – Master Data Synchronization – Customer/Vendor Integraiton – Business Partner Settings – Settings for Vendor Integration – Field Assignment for Vendor Integration – Assign Keys – Define Number Asignment for Direction Vendor to BP.

Danach müssen Sie den gesamten IMG Pfad Cross-Application Components – Master Data Synchronization – Customer/Vendor Integration – Business PArtner Settings – Settings for Customer Integration – Field Assignment for Customer Integration – Assign Attributes durchlaufen – sowohl für die Kontaktperson als auch für den Debitor generell.

Synchronisation starten über MDS_LOAD_COCKPIT

Jetzt, da Sie sicher sind, dass das Customizing passt, müssen Sie die eigentliche Daten Synchronisation anstarten. Nutzen Sie hierzu den Report MDS_LOAD_COCKPIT. Dieser erstellt einen Business Partner für jeden Kreditor oder Debitor im System. Damit Business Partner nicht doppelt erstellt werden, müssen Sie die zuvor beschriebenen Customizing Steps eben sauber durchgeführt und die beiden Entitäten miteinander verbunden haben.

Auch wenn für die Konvertierung keine Downtime notwendig ist, sollten Sie die Konvertierung zu einer Zeit durchführen, an welcher auf dem System nicht all zu viel los ist. Es empfiehlt sich außerdem, die Transkation BP für die Dialognutzung durch die Fachanwender ab diesem Zeitpunkt zu sperren, so dass vom Zeitpunkt der Konvertierung bis zur S/4 System Conversion keine Änderungen mehr durchgeführt werden und somit neue Showstopper für die Migration erzeugt werden können.

Der Report erstellt außerdem die jeweiligen Kontaktdaten, Adressen, BP Rollen sowie die Zahlungsinformationen. Im Report angekommen doppelklicken Sie auf den gewünschten Synchronisationsprozess – also Customer->Business Partner oder Vendor->Business Partner, filtern die affektierten Kreditoren/Debitoren über ihre Nummern oder Kontogruppen, und führen den Report aus. Es empfiehlt sich, beim ersten Lauf nur einige wenige Datensätze auszuwählen, zwischen 10 und 50 an der Zahl.

Nach der Migraiton können Sie im Reiter Monitor mögliche Replikationsfehler analysieren. Klicken Sie dazu im Reiter Monitor auf das PPO Icon, um sich den Status der PPO Orders anzusehen. Es ist wichtig, alle Stammdatenfehler zu beheben, um die Konvertierung abzuschließen.

Über den Report CVI_UPGRADE_CHECK_RESOLVE können Sie sich eine Liste aller Customer/Vendor Entitäten anzeigen lassen, die noch synchronsiiert werden müssen. Sie können sich diese Liste als Datei herunteralden und in das MDS_LOAD_COCKPIT hochladen, um nur die übrig gebliebenen Accounts zu verarbeiten

Nach der Konvertierung auf S/4HANA sollte es keinen Anwendungsfall mehr geben, der Sie dazu nötigt, erneut eine Synchronisation in der Richtung Customer/Vendor->Business Partner durchzuführen. Synchronisationen sollten nur noch in der umgekehrten Richtung statt finden. Eventuell sollten Sie diese Funktionalität also komplett im System sperren.

Check Reports CVI_FS_CHECK_CUSTOMIZING und PRECHEK_UPGRADATION_REPORT

Nach dem Mapping lassen Sie einen Check-Report laufen. Diesen bekommen Sie über SAP Hinweis 1623677 und erreichen ihn dann im Anschluss über Transaktion CVI_FS_CHECK_UST bzw. über den Report CVI_FS_CHECK_CUSTOMIZING. Der Report prüft das Customizing in beide Richtungen. Dies ist genau der gleiche Report, der durch den Software Update Manager einmal im Preprocessing und einmal im Postprocessing ausgeführt wird. Sie sollten diesen vor der System Conversion ausführen, um Show Stopper an dieser Stelle zu verhindern.

Optional können Sie außerdem den Report FSBP_IND_SECTOR_MAPPING_CHECK ausführen, welche das Mapping der Industry Assignments prüft.

Zusätzlich ist der Report aus SAP Hinweis 2216176 auszuführen, den Sie nach Implementierung über die Transaktion CVI_PRECHECK_UPGRADE oder über den Report PRECHECK_UPGRADATION_REPORT erreichen. Dieser prüft, ob alle benötigten CVI Mappings erfolgreich abgeschlossen sind. Falls Ihnen Inkonsistenzen in den Linker Tabellen angezeigt werden, konsultieren Sie SAP Note 974504.

FI/SD – Kundeneigene Erweiterungen unter CVI

Jetzt haben Sie vielleicht schon auf Basis der klassischen Customer/Vendor Logik Erweiterungen implementiert, in denen Sie noch von der klassischen Logik ausgehen. Damit Sie nach erfolgter Konvertierung in die Customer/Vendor Integration weiterhin Ihre Logik abbilden können, stellt der Hersteller diverse BAdIs zur Verfügung, die Sie beispielsweise bei einem Exit nutzen können. Näheres finden Sie im IMG Pfad Cross-Application Components – Master Data Synchronization – Customer/Vendor Integration -> Business Partner Settings -> Business Add-Ins (BAdIs) bzw. in den SAP notes 2309153 und 2295823. Jedes Interface zum Erstellen oder Ändern eines Customer/Vendor Stammdatensatzes muss hierzu den Funktionsbaustein CVI_EI_INBOUND_MAIN aufrufen.

Kundeneigener Code, welcher die oben benannten, obsoleten Transkationen betrifft, muss nicht umgeschrieben werden. Die Transkationsaufrufe werden unter S/4 automatisch an die Transkation BP weitergeleitet.

Wenn Sie unter S/4 CRUD (löschen bedeutet hierbei nur das Deletion Flag zu setzen) Operationen auf Customer/Vendor Stammdatensätze über eine Webschnittstelle durchführen wollen, gibt es hierfür im SAP API Hub einen OData Service.

MM/PP – Storage Location Material Requirements Planning (MRP)

In SAP ERP ist es mögliche, Lagerplätze aus dem Material Requirements Planning auszuschließen oder separat zu planen. Das kann beispielsweise notwendig sein, wenn  die Lager uterschiedliche Werke mit wiederum unterschiedlichen Losgrößen beliefern, oder nicht anhand des Materialverbrauchs eines Werks (engl.: Plant) beliefert werden sollen. In diesem Fall muss das Werk mit einer eigenen losgrößenspezifischen Planung versehen oder ganz von der losgrößenbasierten Planung ausgeschlossen werden.

Diese Planung wurde bereits unter der Business Suite vereinfacht, indem die alte Logik der Lagerplätze (Storage Locations) durch die Logik der MRP Areas ersetzt wird. Dadurch war es möglich, die verschiedenen Lager in verschiedene „MRP Areas“ unterzubringen, ohne ein zweites Werk erstellen zu müssen. Weitere Informationen finden Sie in SAP Note 2268045 – S4TWL – Storage Location MRP. Die Abbildung vergleicht das alte Prinzip (oben in grün) mit dem neuen (unten in blau).

Unter S/4HANA ist nur noch das neue Prinzip der MRP Areas unterstützt. Sie müssen also vor der Konvertierung auf S/4HANA die Umstellung durchführen. Wenn Sie in Ihrem ERP System noch die Storage Location MRP Logik nutzen, sollten sie den Report MRP_AREA_STORAGE_LOC_MIGRATION ausführen. Informationen zum Report erhalten Sie unter SAP Note 2216528.

MM – Verlängerung des Datenelements MATNR in MARA

Das Datenelement bzw. das Datenfeld MATNR, welches etwa in der Tabelle MARA genutzt wird, wird in der maximalen Länge von 18 auf 40 Zeichen verlängert. Die dadurch beeinflussten SAP Datenstrukturen, was Domänen, Strukturen, Tabellentypen, Datenbanktabellen und User Interfaces beinhaltet, müssen entsprechend adaptiert werden.

Diese Erweiterung wird jedoch nach einer Konvertierung nach S/4HANA nicht automatisch aktiviert. Sie muss explizit von Ihnen als Kunde aktiviert werden. Solange Sie die Erweiterung nicht aktivieren, gibt es auch keinen Business Impact. Wenn Sie jedoch die Erweiterung nutzen wollen, müssen Sie sich Gedanken darüber machen, ob Ihre Nebensysteme, die mit dem S/4HANA System kommunizieren, mit längeren Materialnummern umgehen können. Für die Kommunikation mit anderen Business Suite Systemen wie SRM und CRM können Sie SAP Note 2232396 konsultieren.

Des Weiteren könnte es sein, dass Sie in Ihren Eigenentwicklungen Anpassungen vornehmen müssen, um mit dieser verlängerten Materialnummer umgehen zu können. Dazu können Sie die entsprechenden Customer Coding Checks durchführen. Weitere Informationen finden Sie in SAP Note 2267140. Es gibt außerdem einen Pre-Check Report (MFLE_CLS4H_CHECKS_CC), den Sie ausführen können, in SAP Note 2216958.

SD – Sales Simplifications & International Trade Management

Unter S/4HANA  müssen Sie sich zunächst im Sales Bereich mit einigen Simplifications auseinander setzen.

• Der Business Partner Approach (weiter oben bereits diskutiert im Kapitel Customer/Vendor Integration (CVI)) ersetzt den alten ERP SD customer master (SAP Note 2265093).
• S/4HANA Finance Credit Management ersetzt das Business Suite SD Credit Management (SAP Note 2270544)
• S/4HANA International Trade Management ersetzt das Modul SD Foreign Trade (SD-FT) (SAP Note 2223144). Dies ersetzt im Wesentlichen die Funktoinalitäten, die SD-FT damals schon geboten hat, sprich die Bereiche Intrastat, Präferenzabwicklung (Preference Handling – SD-FT-PRE), dokumentenbasierte Zahlung (z. b. über Kreditbrief – letter of credit, SWIFT-Integration, Pflege von Zahlungskonditionen) und die Compliance zu Exportverordnungen (z. B. EFTA). Wer darüber hinausgehende Funktionalitäten braucht, ist weiterhin dazu angehalten, SAP Global Trade Services (SAP GTS) zu nutzen, welches sowohl on-Premise, in der HANA Enterprise Cloud (HEC) oder über Partner Managed Cloud (PMC) verfügbar ist.
• zur Migration der FI Dokumente aus SD-FT kosultieren Sie SAP Note 2520879
• SAP Condition & Contract Settlement ersetzt das Business Suite SD rebates Modul (SD-BIL-RB) (SAP Note 2267377)
• SAP Revenue Accounting ersetzt das Business Suite SD Revenue Recognition Modul (SD-BIL-RR) (SAP Note 2267342)
• Mit S/4HANA können Sie mit Hilfe von ODATA und Open CDS Views einen komplett neuen Approach im Analytics Bereich fahren. Dieser Appraoch ersetzt die klassische Lösung über ERP LIS/ODP (SAP Note 2228056)
• Das Datenmodell für die Preisfindung ändert sich (SAP Note 2267442)
• Es gibt diverse Custom Code Checks für obsolte SD Transaktionen und SD BAPIs (SAP Note 2228098)
• Optimieren Sie die parallele Ausführung von SD Konvertierungsreports für Ihre Conversion Downtime (SAP Note 2353814)
• Optional können Sie das SAP S/4HANA New Output Management konfigurieren (SAP Note 2228611)

FI/CO – New General Ledger Accounting

Die zentrale Finance Note zur Prüfung der Konvertierungsvorbareiten ist der Hinweis 2332030. Wie aus meinem damaligen Blog Post ersichtlich, verändert sich vor allem im FI/CO Bereich das Datenmodell durch die Einführung des Universal Journal erheblich. Diese Änderungen im Datenmodell müssen berücksichtigt und vorbereitet werden.

Eine wesentliche Grundvoraussetzung ist die Migration auf das neue Hauptbuch (New General Ledger Accounting). Grundsätzlich müssen Sie vor einer System Conversion auf S/4HANA Finance bzw. S/4HANA Enterprise Management NICHT auf die neue Hauptbuchhaltung migrieren. Sie können grundsätzlich die Migration auf die neue Hauptbuchhaltung zusammen mit der S/4HANA System Conversion durchführen. Dies bringt jedoch einige Nachteile mit sich. Wenn Sie über die S/4HANA System Conversion auf das neue Hauptbuch migrieren, findet eine rein technische Migration statt. Es werden dabei keine neuen Funktionalitäten wie die Belegaufteilung (Document Splitting) oder die parallele Rechnungslegung (Parallel Ledgers) implementiert. Diese Funtionalitäten müssen Sie im Nachhinein implementieren, und beides innerhalb von ein und dem selben Fiskaljahr durchzuführen könnte einen ziemlich großen Einfluss auf Ihren Geschäftsbetrieb bedeuten.

Es ist daher grundsätzlich empfehlenswert, die Migration auf das neue Hauptbuch und die Einführung des Belegsplittings auf der einen Seite, und die Konvertierung auf S/4HANA auf der anderen Seite, auf zwei verschiedene Fiskalperioden aufzuteilen. Es empfiehlt sich in diesem Zusammenhang, zusammen mit der neuen Hauptbuchhaltung auch die neue Anlagenbuchhaltung einzuführen. Über beide Themen habe ich mich in diesem Beitrag bereits ausgelassen.

Wenn Sie jedoch die entsprechenden Ressourcen freihalten, um innerhalb eines einzigen Projektes beide Schritte (S/4HANA Systemkonvertierung und Einführung der neuen Hauptbbuchalltung) zu stemmen, spricht grundsätzlich nichts dagegen, beides innerhalb des System Conversion Projektes und somit innerhalb ein und derselben Fiskalperiode durchzuführen. Sie sparen damit mitunter sogar Projektkosten. Im Endeffekt ist es also ein Abwägen zwischen der Reduzierung von Komplexität und Risiko auf der einen Seite und der Reduktion der TCO auf der anderen Seite.

Sie wissen noch nicht, ob Sie die neue oder klassische Hauptbuchhaltung verwenden? Die einfachste Möglichkeit, dies zu prüfen, ist die Tabelle FAGL_ACTIVEC. Steht dort im Feld „ACTIVE“ ein X, sind Sie schon auf dem neuen Hauptbuch.

FI/CO – Harmonisierung Ihres Währungskonzeptes

Damit wir diesen Abschnitt erklären können, müssen wir uns erst einmal die wichtigsten Begrifflichkeiten in der Währungskonfiguration unter SAP klären. Bereits unter SAP ECC ist die Funktionalität des Hauptbuchs unter SAP bekannt, mit internationalen Währungstransaktionen umgehen zu können. Darunter fällt beispielsweise die Möglichkeit, die in der lokalen Unternehmenswährung geführten Abschlüsse einzelner Tochterunternehmen, die in der Regel innerhalb von gesonderten Buchungskreisen hinterlegt sind, in einen konsolidierten Konzernabschluss in der Währung des darüberliegenden Mutterkonzerns zu überführen. Dieser wird dann in der Regel auf Ebene des Mandanten definiert. Zu dieser Währungskonsolidierung gehört auch die Echtzeit-Umrechnung von Werten zum Zeitpunkt ihrer Verbuchung in die jeweilige Zielwährung. Um das Konzept nun zu verstehen, hier kurz die Auflistung der wichtigsten Begriffe.

• Transaktionswährung (transaction currency) bzw. Belegwährung (document currency): Die Währung, in welcher eine Transaktion bzw. ein Beleg verbucht wird. In der Regel ist dies die Währung, auf die ein Beleg (z. B. eine Eingangsrechnung) ausgestellt wurde. Obwohl das theoretisch auch eine Kryptowährung wie Bitcoin sein könnte, können im SAP-System nur Währungen nach internationalem ISO 4217 Währungsschlüssel ausgewiesen sind, definiert werden.
• Landeswährung (local currency) bzw. Gesellschaftswährung (company code currency). Diese Währung hinterlegen Sie bei der Konzerngesellschaft (also dem Tochterunternehmen eines Konzerns, welches in der Regel eine Region, ein eine Divison oder eine Produktgruppe repräsentiert), die dem jeweiligen Buchungskreis zugeordnet ist. Dies ist in der Regel die Landeswährung des jeweiligen Firmensitzes der Gesellschaft.
• Hartwährung (hard currency). Eine Hartwährung ist eine landesspezifische Zeitwährung, die in Hochinflationsländern verwendet wird. Sie werden in der Regel von der Bevölkerung – und daher auch im täglichen Geschäftsbetrieb – alternativ zur ursprünglichen Primärwährung bevorzugt verwendet. In vielen Ländern ersetzt beispielsweise der US-Dollar die eigentliche lokale Landeswährung. Sie können eine Hartwährung auf Landesebene definieren. Von dort aus können Sie die Hartwährung dann als Parallelwährung (=zusätzliche Hauswährung) führen und diese für einen Buchungskreis vereinbaren.
• Indexwährung. Eine Indexwährung ist in einigen Hochinflationsländern zur Steuermeldung vorgeschrieben. Auch Sie wird im Detailbild des jeweiligen Landes gepflegt und kann als Parallelwährung (=zusätzliche Hauswährung) für einen Buchungskreis vereinbart werden.
• Konzernwährung (group currency). Dies ist die Währung, in welcher der übergeordnete Mutterkonzern seinen Abschluss tätigt. Die einzelnen lokalen Abschlüsse der Konzerngesellschaften werden in diese zentrale Konzernwährung umgerechnet, damit der Konzern einen konsolidierten Abschluss vorlegen kann.
• Funktionale Währung (functional currency). Eine funktionale Währung wird häufig definiert, wenn die verwendete Gesellschaftswährung (company code currency), welche dem Buchungskreis einer Konzerngesellschaft zugewiesen ist, nicht für einen US-GAAP bzw. IFRS Abschluss geeignet ist. Wenn Sie jedoch vor haben, im Zuge Ihrer S/4HANA Transition eine internationale Rechnungslegung und einen IFRS Unternehmensabschluss anzufertigen, müssen Sie diesen in einer zugelassenen Währung durchführen. Um dies zu bewerkstelligen, wird in der Regel eine sogennante funktionale Währung (functional currency) definiert. Die lokale Buchführung der Gesellschaft wird für den Zweck des IFRS Abschluss dann parallel in diese funktionale Währung überführt.
  
  Ein anderer Grund für eine funktionale Währung kann sein, dass die primäre Währung, in welcher die Gesellschaft seine Ausgaben und Einnahmen generiert und tätigt, sich von der lokalen Landeswährung unterscheidet. Nehmen Sie als Beispiel einen Konzern mit Firmensitz in den USA, der einen Subsidiär in Mexiko betreibt. Die Gesellschaft produziert Teile und Teilproduktionen für die deutsche Mutter und liefert diese aus. Obwohl die Gesellschaft hierfür zwar im mexikanischen Inland Rohstoffe über die lokale Landeswährung (MXN) einkauft, verschifft sie die Teilerzeugnisse an die Mutter in US-Dollar und erhält von dieser auch die Finanzierung in US-D. Der transaktionale Anteil des US-Dollars in den Cashflows des mexikanischen Fertigers überwiegt, deshalb der US-Dollar zur Erstellung der Steuermeldung verwendet wird.
• Objektwährung (object currency). Eine Objektwährung wird einem Controlling-Objekt zugewiesen. Ein solches Objekt stammt also aus dem internen Rechnungswesen und stellt in der Regel einen Kostenfaktor dar. Es kann sich hierbei also beispielsweise um einen Innenauftrag oder um eine Kostenstelle handeln. Hält eine Gesellschaft beispielsweise Gebäude im Ausland, kann es Sinn machen, diesen Objekten die lokale Landeswährung des Objektstandortes zuzuweisen. Oder wenn die Cashflows eines Innenauftrags aufgrund größtenteils in Fremdwährung abgeleistet werden (etwa aufgrund von Nearshore-/Offshore-Anteilen in der Leistungserbringung), kann es Sinn machen eine gesonderte Objektwährung zuzuweisen.

Viele Kunden haben bei der Transition nach S/4HANA das Problem, dass Sie die Führung von parallelen Währungen und die Führung einer Konzernwährung im Quellsystem noch nicht aktiviert haben. Ihre Umstellung auf SAP S/4HANA dient in diesem Zusammenhang als Chance, Ihr Währungskonzept zu harmonisieren und zu konsolidieren. Gleichzeitig stellt diese Chance aber auch eine Herausforderung dar. Denn Belege in einer offenen Periode, die Sie in der Vergangenheit beispielsweise in einer Altwährung gebucht haben, müssen nach der Umstellung nach S/4HANA konvertiert werden, wenn Sie sich beispielsweise dazu entscheiden, eine neue Konzernwährung zu aktivieren. Grund für diese Entscheidung könnte zum einen das Erstellen eines konsolidierten Konzernabschlusses, zum Anderen die Erfüllung buchhalterischer Regelungen bei der internationalen oder lokaeln Rechnungslegung (z. b. US FASB 52), oder die simple Tatsache sein, dass Ihre Financial Analysts dazu in der Lage sein sollen, zu jedem Beleg sofort den Betrag in Konzernwährung sehen zu können.

Nun kann es aber sein, dass sich Ihre Organisation ursprünglich gegen die Aktivierung der Konzernwährung entschieden hat. Unter SAP ECC war die hierzu notwendige Datenhaltung nämlich redundant und erhöhte damit das Datenvolumen Ihres Systems und die Abfragezeiten. Unter S/4HANA können Sie jedoch dank des neuen Datenmodells und der in-Memory Fähigkeit von SAP HANA ohne redundante Datenhaltung nun mehrere parallele Währungen führen. Ein anderer Grund für die ursprüngliche Entscheidung gegen die parallele Währungsführung könnte sein, dass Ihr Unternehmen ursprünglich nur in einer Region mit einer lokalen Währung tätig war. Über die Jahre könnten Sie aber mittlerweile expandiert sein, was die Notwendigkeit für die Konzernwährung aufkommen lässt.

Vielleicht haben Sie aus historischen Gründen bereits die Erstellung eines konsolidierten Konzernabschlusses ohne die Aktivierung der Konzernwährung etabliert. Mögliche Workarounds, die dies ermöglichen, sind beispielsweise die Reportingfunktionalitäten von SAP BI, die Erstellung eines Special Purpose Ledger (SPL bzw. FI-SL) oder die Installation diverser Drittanbieteraddons. Vielleicht würden Sie aber gerne diese Workarounds loswerden und zum Standard zurückkehren. Ihre S/4HANA Conversion ist die Gelegenheit dafür.

Dabei muss jeder Beleg von seiner jeweiligen ihm eigenen Transaktionswährung einmal in die Gesellschaftswährung, einmal (falls notwendig) in die funktionale Währung und einmal (falls aktiviert) in die Konzernwährung umgewandelt werden. Diese 1-3 Transformationsvorgänge geschehen nicht automatisch, wenn Sie die Konzernwährung aktivieren. Nach Aktivierung der Konzernwährung werden lediglich künftige Transaktionen und Belege in der Konzernwährung gebucht, nicht jedoch die alten Belege konvertiert. Sie können also nicht einfach mal so im Live-System das Customizing ändern und denken, alles wird gut.

Nun gibt es grundsätzlich zwei Ansätze dafür, das Prinzip der Konzernwährung in ein SAP Live-System zu implementieren. Die klassische Methode wird in SAP Note 39919 erläutert. Ein alternativer Approach ist die Durchführung einer S/4 Conversion nach dem sogenannten System Landscape Optimization (SLO) oder auch „Shell“ Ansatz genannt. Dabei wird eine leere S/4HANA Greenfield Hülle erstellt und gecustomized, und erst im Nachhinein werden die entsprechenden Stamm- und Bewegungsdaten aus dem Quellsystem mit entsprechenden Transformationsregeln in diese Hülle übertragen.

Der wesentliche Unterschied zwischen den beiden Vorgehensweisen: Die erstere Umstellung führen Sie VOR der S/4HANA System Conversion durch (und zwar mit mehreren Monaten Vorlaufzeit im Rahmen eines Vorprojekts), die zweitere nach der Implementierung der eigentlichen S/4HANA Hülle (im Rahmen des S/4HANA Conversion Projekts).

FI/CO – Simplification Checks

Vor der Durchführung der Konvertierung sollten Sie außerdem diverse Prüfungen durchführen. Einige davon dienen der Evaluierung der Simplification Items, andere sammeln Daten für den Abgleich der FI-Daten nach erfolgter Konvertierung. Führen Sie den Report /SDF/RC_START_CHECK (ersetzt den älteren Report FINS_MIG_PRECHECK_CUST_SETTINGS) aus, um die Implementierung der notwendigen Simplification Items im Quellsystem zu prüfen, bevor Sie mit der System Conversion beginnen.

FI-AA: Prüfen der Voraussetzungen für die neue Anlagenbuchhaltung

Alles zum Thema neue Anlagenbuchhaltung werde ich an dieser Stelle nicht nochmal wiederholen, weil ich auf das Thema bereits in diesem Blog Post eingegangen bin. Einige der dort erwähnten Tätigkeiten müssen ausgeführt werden, um die notwendigen Voruassetzungen für den Umstieg auf die neue Anlagenbuchhaltung unter S/4 zu schaffen. Dies beinahltet auch die Vorarbeiten für die Aktivierung der neuen Abschreibungsrechnung sowie die Prüfung der Währungseinstellungen

Standardisierung / Simplifizierung Ihrer Geschäftsprozesse

Ihre Umstellung auf SAP S/4HANA ist die Gelegenheit für eine Vereinfachung Ihrer Geschäftsprozesse. Ein typisches Beispiel könnte etwa der Umgang mit nicht-auftragsbezogenen Eingangsrechnungen sein (non-purchase order invoices, Non-PO invoices). Vielleicht ist es derzeit bei Ihnen so, dass jedwede Eingangsrechnung ohne vorherigen Auftragsausgang immer von einem Vorgesetzten genehmigt werden muss, bevor sie ausgezahlt wird, und das unabhängig von ihrem Betrag.

Ein Ansatz in diesem Beispiel wäre etwa, non-PO invoices nur noch zur Genehmigung vorzulegen, wenn entweder die Einzelrechnung einen gewissen Betrag überschreitet oder der hinterlegte Lieferant im Laufe einer Fiskalperiode einen gewissen Gesamtumsatz übersteigt. Dadurch werden die genehmigenden Ressourcen freier und können Ihre Aufmerksamkeit mehr auf das wesentliche richten. Ein derartiges Prozess-Redesign lässt sich wunderbar in ein S/4HANA Transitionsprojekt.

Line of Business Vorbereitungen in Business Downtime

Alle offenen Belege durchbuchen oder löschen

Nach der Isolation des Systems (Schnittstellen und Useranmeldungen wurden gekappt) sollten Sie noch einmal prüfen, ob es im System noch offene Belege gibt. Diese sind in Vorbereitung auf den darauffolgenden periodenabschluss entweder zu buchen oder mit dem Löschzeichen zu versehen.

Periodenabschluss vorbereiten für den Cut-Over

Es ist empfehlenswert, die S/4HANA System Conversion mit einem Periodenabschluss zu verbinden. Schließen Sie die Fiskalperiode über Transkation OB52 und die Controlling Periode über OKP1 und dokumentieren Sie die Ergebnisse.

FI/CO: Consistency Checks

Sammeln Sie über folgende Reports Daten über ihre Finanzdaten – im Altsystem und im Neusystem.

• Sachkontenstämme: Report RFSVKZ00
• Bilanz- und GuV:Report RFBILA00
• Kreditorenstämme: Report RFKKVZ00
• Sachkontensalden: RFSSLD00
• Kreditorensalden: Report RFKSLD00
• Debitorensalden: RFSDLD00
• Abstimmung der Ergebnisse der Kontenkorrentkontenschreibung: RFKKBU00 mit den Reports RFKSLD00 und RFDSLD00
• Offene Posten Kreditoren: RFKOPO00
• Offene Posten Debitoren: RFDOPO00
• Belegkompaktjournal: RFBELJ10
• Dauerbuchungsurbelege: RFDAUB00
• Anlagen: RAGITT01 und RABEST01
• Kostenstellenberichte und Bestellobligo
• Materialbestand: RM07MBST / RM07MMFI
• Abstimmprogramm Anlagenbuchhaltung: RAABST02
• Umsatzprobe: TFC_COMPARE_VZ (TX FAGLF03, neues Hauptbuch) oder SAPF190 (große Umsatzprobe, klassisches Hauptbuch) – SAP Note 31875 beachten.
• Änderungen der Sachkontenstammdaten: RFSABL00
• Änderungen der Buchhaltungsbelege: RFBABL00 – besondere Vorsicht bei Dauerbuchungen
• Auswertung abgebrochene Buchungssätze: RFVBER00
• Auswertung vorerfasste Belege: RFPUEB00 – fertig buchen oder stornieren
• Auswertung von gemerkten Belegen: RFTMPBEL
• Kontrolle von Dauerbuchungen: RFDAUB00
• Kontrolle von Kreditorenstammdatenänderungen: RFKABL00
• Kontrolle von Debitorenstammdatenänderungen: RFDABL00
• Kontrolle von Bankstammdatenänderungen: RFBKABL0
• Kontrolle von Buchhaltungsbelegänderungen: RFBABL00
• Auswertungen von FI-Buchungen: RFBELJ00
• Änderungsanzeige Kredit-Management: RFDKLIAB
• Vergleich Hauptbuchkonten mit Kostenstellen: RCOPCA44
• Ledgervergleich: RGUCOMP4
• Logistik-Auftragsbestand im Altsystem
• Salden der Kostenstellen: Transaktion S_ALR_87013611
• Vor- und Umsatzsteuer: RFUMSV00
• Anlagebeschaffungen: RAZUGA01
• Rückstellungen: RAABGA01
• Report 1SIP (Voraussetzung: keine incremental Conversion darf laufen – prüfen über Transaktion ICNV)

Vergleichen Sie außerdem die folgenden Transaktionen sowohl im Alt- als auch im Neusystem

• FAGLB03
• FBL3N
• FBL5N
• FBL1N
• ME2N
• ME2L
• MB5B
• FD10N

Zusätzliche Vergleichs-Reports und -Transaktionen können im System Conversion Guide gelistet sein.

DaFRK

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

https://www.andreas-loibl.eu

Der Beitrag SAP S/4HANA System Conversion: Line of Business Vorarbeiten erschien zuerst auf DaFRK - Online Brainware for IT Professionals.

Das Szenario kommt eher aus der frühen Zeit von SAP HANA. Damals waren viele Unternehmen noch nicht dazu bereit, ihr altbewährtes und stabiles System abzulösen und mit der Migration auf SAP HANA ein Risiko einzugehen. Es gab die Angst, dass SAP HANA nur ein Versuch von SAP wäre, Kollaborationskosten mit anderen Datenbankherstellern wie Oracle, IBM oder Microsoft zu sparen. Die Befürchtung war, dass die SAP-eigene Datenbank an die Stabilität und die Exzellenz von etablierten Datenbankmanagementsystemen nicht herankommt, und sich mit einer Migration einen negativen Business Impact ins Haus holt.

Um diese Sorgen der Kunden zu adressieren, ermöglicht der Hersteller seinen Kunden, die SAP HANA Datenbank „neben dem eigentlichen System“ zu betreiben. In diesem Ansatz werden die Daten aus der traditionellen Datenbank, beispielsweise einer Oracle, in Near Real Timen die SAP HANA Datenbank repliziert.

In der heutigen Zeit kennt man eigentlich nur noch den integrierten Ansatz, in welchem die ursprüngliche AnyDB Datenbank der Applikation durch eine SAP HANA Datenbank abgelöst wird. Der Vollständigkeit halber möchte ich allerdings in meinem Blog diese architektonische Möglichkeit dokumentieren, weil mich auch schon Kunden gefragt haben, was es denn mit den „HANA ERP Accelerators“ auf sich hat. Das und viele weitere Fragen klären wir in diesem Beitrag.

Der Data Mart und der Akzelerator Ansatz

Nein, ich habe mich nicht verschrieben. Der „Accelerator Approach“ wird tatsächlich so eingedeutscht, wie es in der Überschrift der Fall ist. Naja, jedenfalls: Wenn sich Kunden für einen Side-by-Side Ansatz entschieden haben, muss nun entschieden werden, wie die replizierten Daten der HANA Datenbank angesprochen werden sollen.

Man unterscheidet hierbei zwischen dem Data-Mart Ansatz und dem Akzelerator Ansatz. Die Abbildung verdeutlicht den Unterschied zwischen beiden Ansätzen. Da beide Varianten zum Side-by-Side Approach gehören, werden zunächst einmal die Daten des eigentlichen SAP Systems (etwa SAP ERP) von der klassischen Datenbank nach SAP HANA repliziert.

Beim Data Mart Approach werden die Daten auf die SAP HANA Datenbank repliziert, jedoch fragen die Standard-Transaktionen im SAP ERP System die transaktionalen Daten lesend immer noch über die AnyDB ab. Die Power von SAP HANA kommt also nur dann zum tragen, wenn man über externe Analysetools wie Lumira oder BusinessObjects auf die Daten zugreift. Der Zugriff geschieht hierbei häufig über vordefinierte Views, beispielsweise über SAP HANA Live. Die Analyse über diese Frontend Werkzeug ist nun wesentlich performanter als in der traditionellen Welt, der ABAP Stack bleibt davon jedoch unberührt.

Beim Accelerator Approach hingegen werden die Standard-Transkationen des SAP Systems so angepasst, dass der lesende Zugriff auf die Daten nicht direkt auf die AnyDB abgesetzt wird, sondern auf die SAP HANA Datenbank weitergeleitet wird. Ausschließlich lesende Anfragen werden also auf der HANA Datenbank abgesetzt und nicht auf der Quelldatenbank. Dies hat den Vorteil, dass der ABAP Stack bei lesenden Datenbankzugriffen von der Performance der HANA Datenbank profitiert.

Es gibt mittlerweile mehrere dieser Beschleuniger, der erste davon, der CO-PA Accelerator, war etwa für die Beschleunigung der Wirtschaftlichkeitsanalyse (TX KE30) zuständig. Es gibt einen breiten Fundus von SAP-Hinweisen zu den ERP Accelerators (…1654255, 1617718, 1664155, 1714702, 1671487, 1787035, 1654782, 1671986, 1658252, 1671486, 1912066, usw.).

DaFRK

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

https://www.andreas-loibl.eu

Der Beitrag SAP HANA Side-by-Side Ansätze mit AnyDB erschien zuerst auf DaFRK - Online Brainware for IT Professionals.

Multiple Components on HANA – was heißt das?

Sie können auf einem einzigen SAP HANA Datenbankserver mehrere Applikationen betreiben. So könnte es beispielsweise sein, dass Sie nur einen einzigen SAP HANA Datenbankserver installiert haben, auf diesem jedoch sowohl ein SAP ERP on HANA als auch ein SAP BW on HANA betrieben wird.

Der Hersteller SAP bietet hierzu verschiedene Szenarien: Multiple Components on One System (MCOS), Multiple Components on one Database (MCOD) und Multitenant Database Containers (MDC). Einfach gesagt ist der Unterschied zwischen diesen Betriebsmodi folgender:

• Bei Multiple Components on One System (MCOS) installieren Sie auf einem einzigen Betriebssystem mehrere SAP HANA Datenbankserver. Es sind also im Endeffekt zwei sogenannte Instanzen, die jedoch auf ein und dem selben physikalischen oder virtualisierten Betriebssystem laufen.
• Bei Multiple Components on One Database (MCOD) laufen die beiden Applikationen nicht nur auf dem selben SAP HANA Datenbankserver bzw. der selben SAP HANA Instanz, sondern auch noch in der selben Datenbank. Eine Trennung wird hierbe auf Schema-Ebene realisiert. Das heißt, die Applikationen teilen sich gemeinsame Datenbankkomponenten, wie etwa die Datenbankuser, die Persistenz und die Konfigurationsparameter. Die Daten sind jedoch nach Schema getrennt und der Zugriff auf diese Daten wird auch auf Schema-Ebene über Berechtigungen geregelt.
• Bei Multitenant Database Containers (MDC) haben Sie innerhalb einer SAP HANA Instanz mehrere sogenannte Tenant Datenbanken. Sie können sich die SAP HANA Instanz hierbei wie ein Mietshaus vorstellen, in dem mehrere Mieter (die Tenant Datenbanken) einziehen können. Dabei können diese Mieter einziehen (eine neue Tenant Datenbank kommt hinzu), aber auch ausziehen (eine Tenant Datenbank wird gelöscht bzw. in eine andere Instanz verschoben). Jede Tenant Datenbank hat ihre eigenen User, ihre eigene Persistenz und ihre eigenen Konfigurationsparameter.

SAP HANA 2.0 – Wie funktioniert Multitenancy

Wichtig zu verstehen ist, dass Sie sich nur dann noch gegen MDC entscheiden können, solange Sie unterhalb von SAP HANA 2.0 SPS01 operieren. Ab SAP HANA 2.0 SPS01 gibt es nur noch den Operationsmodus „Multitenant Database Containers“ (MDC) gemäß SAP Note 2423367. Das frühere Standard-Deployment mit nur einer Datenbank wird quasi in Zukunft so realisiert, dass es am Anfang nur eine Tenant Datenbank gibt, der aber später weitere hinzugefügt werden können.

Sie können das Multitenant Database Containers Szenario auch unter HANA 2.0 mit den anderen beiden Betriebsmodi – MCOS und MCOD – kombinieren, solange Sie sich an die weiter unten diskutierten Einschränkungen halten. Jedoch gibt es nicht wirklich einen praktikablen Grund dafür, warum Sie das tun sollten.

Zu Beginn einer HANA (ohne zugehörige Installation der Applikation über beispielsweise den SWPM) im Operationsmodus MDC gibt es eine SYSTEM Datenbank und noch keine einzige Tenant Datenbank. Die erste Tenant Datenbank müssen Sie erst erstellen. Jede einzelne Tenant Datenbank bekommt ihr eigenes Port-Mapping, mit der sie die Datenbank auf ISO/OSI Layer 4 ansprechen können. Standardmäßig können Sie maximal die Ports für 20 Tenant Datenbanken reservieren, weswegen es ohne weitere Konfiguration ein Limit von 20 Tenant Datenbanken auf der MDC Instanz gibt. Sie können jedoch durch entsprechende Konfigurationsschritte weitere Ports reservieren und damit die Limitierung übergehen (SAP Note 2101244). Es gibt derzeit ein theoretisches Limit von 2000 Tenants (Quelle: SAP note 2104291).

Auf der System-Datenbank läuft der Nameserver. Über diesen Port erreichen sie also datenbankübergreifend zentrale technische Komponenten wie das Monitoring der HANA-Systemlandschaft sowie die Konfiguration der HANA Instanz. Alle HANA-Prozesse, die keine datenbankbezogenen Informationen persistieren, laufen auf der zentralen Systemdatenbank. Darunter zählen neben dem Nameserver beispielsweise der Compileserver und der Preprocessor Server, nicht jedoch der Indexserver und die XS-Engine. Die datenbankbezogenen Informationen werden also in den Prozessen der jeweiligen Tenant Datenbank verwaltet und sind daher nicht über die Systemdatenbank erreichbar. Die zentrale Systemdatenbank verfügt jedoch über ihren eigenen Indexserver, den sogenannten Master Indexserver.

Die SAP HANA Datenbank hat im MDC Szenario einen integrierten HDB Web Dispatcher, der die eingehenden HTTP Requests zuverlässig an die jeweilige SAP HANA XS Engine der jeweiligen Datenbank weiterleitet. Hinweis: Dieser Web Dispatcher ersetzt natürlich nicht den Einsatz eines Reverse Proxys in Ihrer demilitarisierten Zone, wenn Sie aus dem öffentlichen Internet auf die XS Engine zugreifen wollen.

Sie können sich sicher vorstellen, dass die Multitenancy von Hause aus einen Performancevorteil, aber auch gleichzeitig ein Sicherheitsbedenken mit sich bringt: Da alle Datenbanken auf der selben Instanz sind, ist es sehr performant und daher opportun, Daten zwischen den einzelnen Tenant Datenbanken auszutauschen. Noch wie wäre es etwa so einfach gewesen, zwischen einem ERP- und einem CRM-System Materialsätze auszutauschen. Andererseits könnte dies natürlich ein Problem für die Informationssicherheit darstellen. Deswegen können Sie den sogenannten Cross-Tenant Access konfigurieren. Der SAP Hinweis 2196359 bietet Ihnen hierzu die notwendige Unterstützung.

Überblick über die SAP HANA Deployment Szenarien

Zunächst einmal zeige ich die einzelnen Optionen im Detail auf. Die Abbildung visualisiert die Unterschiede zwischen den verschiedenen Szenarien.

• Multitenant Database Containers (MDC)
  • Einziges Szenario, in welchem mehrere Datenbanken auf einer einzigen HANA Instanz laufen
  • einziges Szenario, in welchem mehrere BW Systeme auf der selben Datenbank laufen dürfen (SAP Note 1666670)
  • In diesem Szenario sind nicht nur die Daten getrennt, sondern auch die Datenbank-Benutzer. Jede Datenbank hat ihre eigenen User
  • Durch ein Mapping der User vom Quell-Tenant zum Ziel-Tenant wird ein Cross-Tenant Lesezugriff möglich
  • Für jede Datenbank können Ressourcen allokiert werden (CPU + RAM, aber nicht I/O und Netzwerkbandbreite)
  • Häufig ausgewählt von Cloud Anbietern, die auf einer einzigen HANA Installation mehrere Kunden bedienen wollen.
  • Wartung nur noch auf einer einzigen Instanz nötig, dafür Business Impact bei allen Anwendungen
  • Failover einer Anwendung bedeutet automatisch Failover aller anderen Anwendungen (All or Nothing).
  • MCOD ist innerhalb von MDC möglich. Das heißt innerhalb einer MDC Tenant Datenbank kann wiederum ein MCOD-Szenario gefahren werden.
  • MDC ist grundsätzlich für alle SAP-Applikationen produktiv freigegeben. Die Restriktionen bzw. die Freigabelisten aus den Notes für MCOD (SAP Note 1661202, 1826100) greifen daher NICHT für MDC, außer wenn innerhalb einer MDC Tenant Datenbank wiederum ein MCOD Szenario gekapselt wird.
  • Sizing für MDC: Additiv, SAP Notes 1774566, 1825774, 2121768. SAP HANA HW Configuration Check muss „pro Applikation“ durchgeführt werden. SAP Note 1943937.
  • Jede Tenant Datenbank hat ihren eigenen Index Server, der für sich genommen (bereits ohne Daten) jeweils 8 GB RAM benötigt.
  • SAP HANA 1.0 Standard Deployment Datenbanken müssen erst per Systemkopie in eine HANA 1.0 MDC-Datenbank kopiert werden, damit diese dort dann gebackupt und in der Zieldatenbank wiederhergestellt werden kann (SAP Note 2096000)
  • Parameter allocationlimit und max_concurrency müssen konfiguriert werden.
  • Einige Funktionen sind erst ab HANA 2.0 SPSXX verfügbar, SAP Note 2096000.
• Multiple Components in one System (MCOS), auch „Multi-SID“
  • Nicht mehr empfohlen, stattdessen MDC verwenden (gemäß SAP Note 2096000)
  • Mehrere HANA Instanzen laufen auf einem System
  • unter SAP HANA 1.0 damals am häufigsten genutzte Variante für den Betrieb des SAP Solution Manager 7.2 (eine Instanz für ABAP und eine für Java Stack)
  • Nur für Produktion freigegeben bei Scale-Up Szenario, Scale-Out nicht supported (SAP Note 1681092)
  • Scale-Out freigegeben für Non-Production.
  • Wartung von Betriebssystem und Hardware wird vereinheitlicht, die Wartung der Datenbank ist aber getrennt und erfolgt daher doppelt.
  • Das Allocation Limit muss für beide Instanzen konfiguriert werden, damit sich nicht eine HANA Instanz alleine sämtliche Ressourcen schnappt.
  • Failover betrifft nur die jeweilige instanz.
• Multiple Components in one Database (MCOD)
  • MCOD ist innerhalb von MDC möglich. Das heißt innerhalb einer MDC Tenant Datenbank kann wiederum ein MCOD-Szenario gefahren werden.
  • Innerhalb einer Datenbank gibt es mehrere Schemata für die verschiedenen Applikationen
  • Die beiden Schemata sind in der selben Datenbank, das heißt die selben User können sich an der Datenbank anmelden, Zugriffsberechtigungen für die Schemata müssen gesteuert werden, SYSTEM User sieht beide Schemata.
  • Nur bestimmte Applikationen dürfen zusammen in einer Datebank betrieben werden. Die hierzu konsultierenden SAP Notes sind 1661202, 1666670 (BW) und 1826100 (Suite on HANA).
  • Steuerung der Ressourcen zwischen den Datenbanken ist nicht wirklich möglich.
  • Sizing: additiver Approach.
  • Freigegeben für Scale-Out. Aber: Eine Datenbank im Scale-Out bedeutet: Alle darauf laufenden Anwendungen sind automatisch Scale-Out.
  • Backup/Recovery sowie Failover betrifft beide Applikationen.
  • Systemkopie nicht getrennt nach Applikation möglich.

Was ist empfehlenswert? MCOD, MCOS oder MDC?

Die Beratung ist an dieser Stelle aus meiner Sicht mittlerweile relativ einfach. Multitenant Database Containers (MDC) ist der Betriebsmodus der Wahl. Denn spätestens wenn Sie auf SAP HANA 2.0 SPS01 oder später upgraden wollen, müssen Sie auf diesen Betriebsmodus. Sie ersparen sich also den Aufwand der späteren Konvertierung Ihrer Datenbank in die Multitenancy, wenn Sie Ihre Datenbank von Anfang an so implementieren.

Sie können zwar grundsätzlich ein MCOS oder MCOD Szenario verwenden. Z. B. könnte man über das MCOS Szenario nachdenken, wenn man explizit nicht will, dass zwei verschiedene Applikationen einen gemeinsamen Failover in der SAP HANA System Replication durchführen müssen. Auf der anderen Seite: Wenn die Datenbank-Instanz, das Betriebssystem oder die Hardware abschmiert, müssen Sie ohnehin beide Applikationen auf den Sekundärknoten wechseln.

SAP HANA MDC FAQ

In dieser Sektion beantworte ich kurz die häufigsten Fragen zu SAP HANA Multitenant Database Containters (MDC), die Kunden auf den Nägeln brennen.

DaFRK

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

https://www.andreas-loibl.eu

Der Beitrag SAP HANA Betriebsmodi | MDC | MCOD | MCOS erschien zuerst auf DaFRK - Online Brainware for IT Professionals.

Oft werde ich gefragt, was denn die einzelnen Sicherheitseinstellungen bei der Erstellung und Konfiguration von Web Services bedeuten, insbesondere wenn diese auf dem SOAMANAGER aufgesetzt werden. Dieser Thematik wollen wir uns heute einmal widmen. 

Im Wesentlichen soll es darum gehen, all diejenigen abzuholen, die noch nie mit dem SOAMANAGER und seiner WSDL-Funktionalität zu tun hatten, aber jetzt mit der Technologie arbeiten müssen und sich sorgen um die Security Konfiguration machen.

Für mich ist die Thematik immer sehr amüsant, weil ich sowohl SAP Kunden betreue, die noch nie einen Webservice definiert (geschweige denn entwickelt) haben, als auch Entwickler, die nicht aus der SAP Welt kommen und innerhalb ihrer Applikation mit SAP sprechen wollen. Die Technologien beider Seiten sind für die jeweils andere immer ein Buch mit sieben Siegeln.

Die Desktop- und Web-Entwickler holen den Rosenkranz aus dem Nachtkästchen, wenn es um CPIC bzw. RFC geht – und die SAP Anwender sehen WSDL und Webschnittstellen im Allgemeinen als Alien-Technologie aus einer vergessenen Zeit an.

In meinem konkreten Beispiel ging es beim Kunden konkret darum, dass man im Bezug auf die Konfiguration der Enterprise Services im SAP System bei einem Audit aussagefähig sein wollte. „Warum sind unsere Services so konfiguriert, wie sie es sind, und wie können wir sie noch weiter absichern?“.

Gleichzeitig können Sie dir gezeigten Erläuterungen jedoch auch zur Bewertung bzw. Auditierung von SOAMANAGER-Einstellungen verwenden. Lesen Sie unbedingt bis zum Ende, der Kontext der Konfiguration eines Service Consumer oder Service Provider ist bei der Bewertung wichtig!

Was ist überhaupt der SOAMANAGER?

Wozu ist denn der SOAMANAGER überhaupt gut? Die Technologie ist im wesentlichen dazu da, ABAP-Funktionsbausteine des SAP-Systems als Web Services zur Verfügung zu stellen, und im Gegenzug diese von anderen SAP-Systemen zu konsumieren. 

Zwar kann der SOAMANAGER auch andere WSDL Web Services konsumieren, aber im Wesentlichen wird er im SAP Umfeld vor allen Dingen zur Bereitstellung von ABAP Geschäftslogik über das Web genutzt.

Was ist denn jetzt schon wieder WSDL?

WSDL steht für Web Services Description Language und ist ein offizieller Standard des W3C. Dabei handelt es sich um einen XML Dialekt, welcher einen Web Service beschreibt.

Ein WSDL Web Service arbeitet mit einem sogenannten Binding. Der Web Service kann mehrere Aktionen haben, zum Beispiel Auslesen (bzw. Abrufen) oder Abspeichern (bzw. Senden) von Daten. Jede dieser Aktion wird mit einem logischen Port verknüpft. Ein WSDL Web Service kann also über mehrere logische Ports aufgerufen werden.

Wenn Sie im SAP System einen Web Service definieren, erstellen Sie meistens ein entsprechendes WSDL Dokument. Dieses WSDL Dokument definiert die verschiedenen Funktionen, die der Web Service nach außen hin anbietet.

Diese Funktionen können nun auf unterschiedliche Art und Weise konsumiert werden. Die zwei gängigsten Beispiele ist ein Konsum eines Web Service über SOAP oder als RESTful Service.

SOAP und REST Services über den SOAMANAGER

Sowohl das Simple Object Access Protocol (SOAP) als auch jede Form von Representational State Transfer (REST) Protokollen sind für die eigentliche Kommunikation zuständig. Sie übertragen also Daten an den Service, die dieser dann mit Hilfe seiner angebotenen Funktionen interpretiert und manipuliert.

Die beiden Ansätze unterscheiden sich in der Art und Weise, wie diese Datenübertragung statt findet. SOAP unterstützt ausschließlich den XML-Standard. Das heißt zu zu übertragende Daten müssen in eine XML-Struktur überführt werden, bevor der Web Service aufgerufen wird.

Ein RESTful Web Service versteht hingegen verschiedene Datenformate. Neben XML können die zu übertragenden Daten auch in einem HTML- oder JSON-Dokument enkodiert sein. Vor allen Dingen JSON ist in dieser Hinsicht wesentlich schlanker als XML und reduziert dadurch den zu übertragenden Brutto Datenpayload. RESTful Services werden daher besonders gerne im Mobile Umfeld verwendet.

Im SAP Umfeld kennen wir alle ein RESTful Web Service Protokoll: Das von Microsoft implementierte OData Protokoll. Es basiert auf JSON und ist eine sehr weit verbreitete Implementierung der REST Architektur.

Wie erstellt man in SAP einen Webservice?

Die klassische Vorgehensweise zur Erstellung eines Web Services (wir reden jetzt nicht von einem OData Service über SAPUI5 und das NetWeaver Gateway, sondern über die ABAP Welt) ist wie folgt:

1. Sie erstellen in der SE37 einen ABAP Funktionsbaustein mit der gewünschten Web Service Funktionalität und setzen diesen im Reiter Attributes -> Processing Type auf „Remote-Enabled“. Damit kann der Funktionsbaustein aus der Ferne aufgerufen werden. Erstmal allerdings nur über RFC und nicht über das Web.
2. Dafür müssen wir einen Webservice erstellen. Dies geht im Funktionsbaustein im Menü unter Utilities -> More Utilities -> Create Web Service -> From the Function Module. Die Einstellungen, welche Sie im Wizard tätigen, können Sie nachträglich auch noch ändern.
3. Sie öffnen nun die Transkation SOAMANAGER. Dort konfigurieren Sie nun das WSDL Dokument zu diesem Web Service und erstellen dadurch die sogenannten Bindings. Sie tun dies im Reiter Service Adminisration -> Web Service Configuration. Filtern Sie nach Object Name und suchen Sie den soeben erstellten Web Service.
4. Wählen Sie den Service auf und begeben Sie sich in den Reiter Configurations. Wählen Sie „Create Service“. Im Folgebildschirm geben Sie unter „Service Name“ den Namen des Services ein. Nun legen Sie eines von eventuell mehreren Bindings für diesen Service an. Im Punkt Provider Security können Sie nun die ersten Sicherheitseinstellungen für dieses Binding festlegen. Genau diesen Schritt werden wir genauer in diesem Posting durchleuchten
5. Nach Abschluss der Konfiguration aktivieren Sie den Service und generieren dadurch die WSDL Definition und eine URL zum Aufruf des Services. Sie können den Service im Anschluss beispielsweise über soapUI testen, indem Sie die .wsdl-Datei des Services downloaden und in soapUI laden.

Wie sichert man den SOAMANAGER ab?

Reden wir nicht mehr um den heißen Brei herum und kommen zu dem, was den Kunden (und Sie als Leser) am brennendsten interessiert. Um einen Web Service beziehungsweise den SOAMANAGER ordnungsgemäß abzusichern, müssen Sie auf verschiedenen Ebenen schrauben.

• In der Konfiguration des Web Services
• In der Konfiguration des SOAMANAGER
• In der Konfiguration des Internet Communication Manager (ICM)

SAP Web Service Sicherheitsvoreinstellungen

Beginnen wir mit Konfiguration des Web Service an sich. Hierzu begeben Sie sich zunächst über die SE37 bzw. die SE80 in die Konfiguration des Funktionsbausteins. Dort finden Sie die entsprechende Service Definition. 

Von dort können Sie in den Reiter Konfiguration wechseln. Begeben Sie sich in den Bereich Sicherheitsprofil, um die ersten sicherheitsrelevanten Einstellungen vorzunehmen. Die Einstellungen, die Sie hier tätigen, gelten als Mindeststandard. Sie können in der Transaktion SOAMANGER abweichende Einstellungen vornehmen, wenn diese einem höheren Sicherheitsprofil als dem in der Servicedefinition gewählten entsprechen. Das im Service definierte Sicherheitsprofil kann jedoch nicht unterschritten werden.

Das Sicherheitsprofil beeinflusst die Folgeeinstellung der Authentifizierungsstufe und der Transportsicherheit. Ein Sicherheitsprofil mit Status Hoch bewirkt eine Authentifizierungsstufe vom Typ Strong. Dies hat zur Folge, dass für die Authentifizierung zwingend X.509 Client-Zertifikate genutzt werden müssen. Der Aufrufer des Web Services muss also mit einem Zertifikat beim Web Service authentifiziert werden.

Die Sicherheitsprofile Mittel oder Niedrig führen beide zur Authentifizierungsstufe Basic. Damit ist eine ganz normale Authentifizierung über Benutzername und Kennwort gemeint. Die beiden Sicherheitsprofile unterscheiden sich in der Position der Authentifizierungsdaten.

Sicherheitsprofil Mittel: Die Authentifizierungsdaten werden im HTTP-Header gesendet und können in der Standardeinstellung sowohl über HTTP als auch über HTTPS gesendet werden.

Sicherheitsprofil Niedrig:  Diese Einstellung führt zu einer sogenannten Document Authentication. Die Authentifizierungsdaten erfolgen anhand der im Dokument gespeicherten Benutzername und Kennwort Kombination.

Sicherheitsprofil None: Führt zur Authentifizierungsstufe None. Es findet keine Authentifizerung statt.

Den Unterschied zwischen der HTTP Header Authentication und der Document Authentication sehen Sie in folgendem Screenshot aus dem soapUI Portal. Orange markiert sehen Sie den übergebenen Wert aus dem HTTP Authentication Header, rot markiert die Anmeldeinformationen im Dokument selbst.

Der Unterschied liegt hier also im Detail. Die Einstellung kann beispielsweise in Zusammenhang mit Intrusion Detection Systemen relevant sein. Eine Header Authentication gilt allgemein als sicherer, weil ohne ein erfolgreiche Header Authentifizierung der Payload, also das Dokument, nicht mal betrachtet werden muss.

Wie Sie sehen, ist das SOAP-Dokument im Standard unverschlüsselt und der Dokumententext einfach nur Base64 enkodiert. Eine Verschlüsselung der Anmeldeverfahren können Sie für beide Verfahren implementieren. Erlauben Sie den Datenaustausch nur per HTTPS, bestimmt der verwendete TLS-Cipher die Verschlüsselung von Header- und Dokument-Authentifizierungsdaten. Diese Einstellung nehmen Sie im Bereich Transportsicherheit vor.

Alternativ zur Verschlüsselung über HTTPS können Sie HTTP-Verkehr erlauben und stattdessen die eigentliche Nachricht, also den SOAP Body, signieren und verschlüsseln. Der HTTP Header kann somit im Klartext versendet werden, der Body ist jedoch in sich verschlüsselt und vom Absender signiert.

Wenn Sie im Wizard zum Anlegen einer Service-Definition die Profile PRF_DT_IF_SEC_HIGH oder nachträglich in der Web Service Konfiguration das Profil Hoch auswählen, muss der Web Service sowohl über eine Verschlüsselung zur Sicherstellung der Vertraulichkeit (HTTPS oder Document Verschlüsselung) als auch über eine Maßnahme zur Sicherstellung der Integrität (in Form von Transportgarantien) verfügen.

Wählen Sie im Wizard hingegen PRF_DT_IF_SEC_MEDIUM bzw. eine Transportischerheitsstufe von Mittel, sind Transportgarantien keine Pflicht. Es wird also verschlüsselt, aber die Datenübertragung kann auch flüchtig geschehen.

Wählen Sie ein Profil von Niedrig, muss weder Verschlüsselung noch Transportgarantie, aber immer noch eine Authentifizierung (über HTTP Header oder Document Authentication) von statten gehen. Wählen Sie ein Transportsicherheitsprofil von None, kann der Service auch ohne Authentifizierung konsumiert werden.

 Wichtiger Hinweis: Es macht wenig Sinn, die Authentifizierung über den HTTP-Header durchzuführen und diesen unverschlüsselt über das Netzwerk zu versenden. Wenn Sie also für die Transportsicherheit nicht auf HTTPS setzen wollen, sondern einfach nur den SOAP Body verschlüsseln, sollten Sie auch die Dokumentenauthentifizierung wählen.

SOAMANAGER Voreinstellungen

Kommen wir nun zu den sogenannten Voreinstellungen des SOAMANAGER. Wie wir bereits gelernt haben, können Sie diese grundsätzlich unterschiedlich von den Voreinstellungen des Web Services pflegen. Sie können die Voreinstellungen jedoch nicht unterbieten, andernfalls ist der jeweilige Web Service nicht konsumierbar. Sie können nur höhere Sicherheitsstandards ansetzen, aber nicht niedrigere.

Begeben Sie sich dazu in der Transaktion SOAMANGER in den Bereich Applikations- und Scenario-Administration -> Administration einzelner Services -> für Services und Consumer-Proxys. Wählen Sie die Details des jeweiligen Services.

Unter Sicherheit auf Transportebene legen Sie fest, ob Sie HTTPS Verschlüsselung nutzen wollen oder nicht. Sie können alternativ im nächsten Bereich, Sicherheit a. Nachrichtenebene, die Verschlüsselung auf Dokumentenebene implementieren, oder lediglich eine Signatur einstellen.

Hinweis: Die Verschlüsselung auf Nachrichtenebene hat den Vorteil, dass sie auch dann noch intakt ist, wenn beispielsweise durch einen Reverse Proxy eine SSL Termination erfolgt. Dadurch ist der Nachrichteninhalt auch im internen Netz noch verschlüsselt. Sie werden jedoch sehen, dass in den Empfehlungen der SAP immer eine Verschlüsselung auf Transportebene erfolgen sollte. Eine Verschlüsselung auf Nachrichtenebene alleine ist nicht im Sinne des Herstellers. Sie ist lediglich eine zusätzliche Absicherungskomponente.

Wenn Sie einen Haken bei Sichere Konversation setzen, wird das Verfahren WS-SecureConversation aktiviert. Voraussetzung ist eine SAP-interne SSL-Vertrauensbeziehung zwischen den beiden Systemen und die Konfiguration der SSF-Funktionalität. Die Einstellung bedeutet nicht, dass die anderen Verfahren per se unsicher sind. Es bedeutet nur, dass ein von SAP empfohlenes Verfahren genutzt wird, in welchem vorab symmetrische Schlüssel ausgetauscht werden, ohne dabei ein asymmetrisches Verschlüsselungsverfahren wie OpenPGP zu nutzen – sondern ein symmetrisches Verschlüsselungsverfahren. Die Option „Signatur und Verschlüsselung“ alleine ist im Endeffekt auch als „sicher“ zu betrachten.

Wenn Sie einen Haken bei Erweiterter Signatur- und Header-Schutz setzen, wird folgendes Verfahren genutzt. Dadurch stellen Sie sicher, dass die Signatur vor ihrer Übertragung verschlüsselt wird. Kommuniziert das als Service Provider fungierende SAP System mit einem anderen SAP-System, werden diese SAP-eigenen Headerdaten verschlüsselt. Wenn das SAP System als Service Consumer fungiert, wird der SOAP Header veschlüsselt. Das sollten Sie tun, wenn Sie beispielsweise die SOAP-Nachricht nicht bereits in HTTPS kapseln.

Im nächsten Bereich, unter Authentifizierungseinstellungen, kommt es stark auf die Voreinstellungen des Web Service an. Wenn Sie im Web Service in der SE80 das Sicherheitsprofil auf Mittel oder Niedrig gestellt haben, können Sie hier eine Benutzeranmeldung über Benutzername und Kennwort einstellen.

Der „ABAP-Service-Benutzer“ ist ein Benutzer auf dem SAP NetWeaver AS ABAP, der zum Aufruf des hinter dem Web Service steckenden Funktionsbausteins per RFC genutzt wird. Es sollte sich hierbei um einen Service-Benutzer handeln, der sich am System nicht interaktiv anmelden kann und minimale Berechtigungen erhält.

Wenn Sie nicht eine Authentifizierung über einen individuellen SAP Benutzer, sondern über einen ABAP Service User entscheiden, geschieht dies oft, weil eine Middleware in die Kommunikation involviert ist. Dieses Szenario spreche ich weiter unten an. Grundsätzlich sollte sich jeder User mit seinem eigenen, persönlichen Benutzer anmelden, um den Service zu konsumieren. Die Verwenndung des ABAP-Service-User ist jedoch in Ordnung, wenn eine technische Komponente die dazwischen sich um die Authentifizierung der Endbenutzer kümmert.

Wenn Sie einen Authentifizeurngsmechanismus für Single Sign-On verwenden (also SPNego, SAP Logon Tickets oder SAML), wird dieser Service Benutzer nicht für den Aufruf verwendet, sondern die Identität des im Konsumentensystem ngemeldeten Benutzer an das Anbietersystem propagiert.

Ein Anwender würde sich zunächst mit seinem Benutzer am Clientsystem anmelden und würde  mit seiner Identität den dahinterliegenden Funktionsbaustein aufrufen. Bei allen anderen Varianten meldet sich der Benutzer zwar mit seinem auf dem Anbietersystem gespeicherten Benutzer an, jedoch erfolgt der Aufruf über den ABAP Service Benutzer.

 Hinweis: Steht bei Authentifizierungsstufe: None, findet keine Authentifizierung statt. Jeder kann den Funktionsbaustein mit den Rechten des ABAP-Service-Benutzer aufrufen.

Der ABAP Service Benutzer benötigt in der Regel die Rolle SAP_BC_WEBSERVICE_CONSUMER. Die anderen WEBSERVICE-Rollen sind in der Regel nicht notwendig. Diese werden wir in einem späteren Kapitel genauer erläutern.

Im letzten Bereich regeln Sie die Authentifizierung.  Damit Sie hier Einstellungen festlegen können, müssen Sie unter Authentifizierungsmethode den Haken bei Keine Authentifizierung entfernen. Unter Authentifizierung auf Transportebene können Sie dann im Anschluss folgende Optionen festlegen

• Benutzer-ID und Kennwort: Benutzer-ID und Kennwort werden über eine Anmeldemakse per HTTP Protokoll übergeben. Bei einem Transport-Sicherheitsprofil von Strong haben Sie diese Auswahlmöglichkeit nicht.
• X.509-SSL-Client-Zertifikat. Die Authentifizierung erfolgt über X.509 SSL/TLS Zertifikate. Hierzu muss eine entpsrechende Vertrauensstellung zwischen den Systemen konfiguriert werden.
• Single Sign-On über SAP-Zusicherungsticket. Die Anmeldung über SAP Logon Tickets gilt wird vom Hersteller grundsätzlich nicht mehr empfohlen. Sofern die Übertragung allerdings per 
• Single Sign-On über SPNego ist ein Verfahren zur Anmeldung an Webservices über Kerberos und gilt als sicher, solange die SNC-Parameter snc/… entsprechend konfiguriert wurden.

Zusätzlich oder alternativ zur Authentifizerung auf Transportebene können Sie auch auf Nachrichtenebene eine sogenannte Dokumentenauthentifizierung konfigurieren. Hierbei stehen Ihnen folgende Konfigurationsmöglichkeiten zur Verfügung. 

Hinweis: Authentifizerung auf Nachrichtenebene erfolgt grundsätzlich unverschlüsselt. Sie können also die Integrität einer Nachricht sicherstellen, aber nicht deren Vertraulichkeit. Sie müssen sie entweder durch eine Verschlüsselung auf Nachrichtenebene oder eine Verschlüsselung auf Transportebene absichern. Diese Einstellung konnten Sie weiter oben tätigen. Weitere Informationen im SAP Help Portal unter Verwendung der Authentifizierung auf Nachrichtenebene.

• Benutzer-ID und Kennwort. Hierbei erfolgt die Authentifizierung über die im abgesendeten XML Dokument hinterlegten Anmeldedaten. Diese sind in der Regel, wie oben gezeigt, unverschlüsselt, wenn Sie weiter oben im Bereich Sicherheit a. Nachrichtenebene keine Verschlüsselung implementiert haben. Um zu verhindern, dass die Authentifizierungsdaten im Klartext übertragen werden, sollten Sie zusätzlich eine Verschlüsselung auf Transportebene (HTTPS) implementieren. Genauer gesagt handelt es sich um das Verfahren WS-Security UsernameToken.
• X.509-Zertifikat. Die Anmeldung erfolgt über eine signierte SOAP-Message, die mit dem auf dem SAP-System hinterlegten Zertifikat übereinstimmen muss. Dies gilt als sicher, sofern das Zertifikat durch einen privaten Schlüssel gesichert ist. Genauer gesagt handelt es sich um das Verfahren WS-Security XML Signature/Encryption.
• Single Sign-On mit SAML 1.1 Assertions. Dieses Verfahren gilt als sicher, sofern Sie beim Service-Provider nicht das auf DSA-basierende Client-Zeritfikat, sondern ein auf RSA basierendes Zertifikat verwenden oder den Haken bei „Sichere Kommunikation“ gesetzt haben. Weitere Informationen dazu erhalten Sie im SAP Help Portal.

Konfigurationsempfehlungen und Anleitungen von der SAP

Sie werden sich jetzt vielleicht denken: Boah! Das ist ja voll der Overkill. Ich wollte eigentlich wissen, wie ich meinen Webservice sicher konfiguriere, und keine Masterarbeit schreiben. Dann kann ich Sie trösten: Die SAP liefert einfach verständliche Konfigurationsempfehlungen aus.

Dort erhalten Sie eine Entscheidungsmatrix, welche Konfigurationsprofile Ihnen bei welchem SAP NetWeaver Release empfohlen werden. Grundsätzlich empfiehlt Ihnen der Hersteller, ein Verfahren zu wählen, bei welchem die Identität des Benutzers auf dem Clientsystem propagiert wird und gleichzeitig Sicherheit auf Nachrichtenebene bietet. 

Andere Einstellungen sollten Sie wählen, wenn Sie keine andere Wahl haben, weil Sie etwa kein Single Sign-On Verfahren nutzen können. Links in der Navigationsleiste erhalten Sie außerdem Konfigurationsbeispiele für AS ABAP und AS Java. Dort wird Ihnen die Konfiguration der empfohlenen Szenarien entsprechend gezeigt.

Eins sollte Ihnen beim Betrachten der Konfigurationsempfehlungen auffallen: Es wird keine einzige Konfiguration empfohlen, bei welcher keine Authentifzierung über einen SAP-Endbenutzer verwendet wird. Ist ja auch logisch, denn niemand soll ohne Authentifzierung dazu in der Lage sein, einen Funktionsbaustein zu nutzen, welcher sensible Daten preis gibt oder verändert.

Warum findet man trotzdem in vielen SAP Systemen Webservices, die in der Laufzeitkonfiguration des SOAMANAGER ohne Authentifizierung konfiguriert werden, sondern stattdessen nur einen ABAP Service Nutzer hinterlegt haben?

Das kann einen legitimen Grund haben. Beispielsweise wenn zwischen dem Service Consumer und dem Service Provider eine Middleware tätig ist. Der Workflow ist dann in der Regel so

• Der Service Consumer meldet sich über einen Authentifzierungsmechanismus an der Middleware an
• In der Konfiguration der Middleware-Komponente sind Benutzername und Kennwort des ABAP Service User hinterlegt, der beim Service Provider hinterlegt wurde
• Die Middleware Komponente ruft den Web Service des Service Providers auf und verwendet dabei den ABAP Service Benutzer und dessen Kennwort, welches zuvor vom Administrator eingepflegt wurde.
• Der Service Provider empfängt den Request über die Middleware und liefert eine Antwort
• die Middleware liefert die Antwort des Service Provider an den authentifzierten Benutzer der Middlewarekomponente aus.

Diese Konfiguration ist per se nicht unsicher. Denn zum einen muss der Administrator Benutzername und Kennwort des ABAP Service User kennen, um sich am Service Provider zu authentifizieren. Zum Anderen, und das ist wichtig, muss sich der Service Consumer, also der Endbenutzer, an der Middlewarekomponente authentifzieren.

Entfällt die Authentifizierung an der Middlewarekomponente jedoch, bedeutet dies wiederum, dass jeder über die Middleware die Schnittstelle nutzen kann, ohne sich mit einem personalisierten User authentifizieren zu müssen. Das ist wiederum aus Sicht eines Security Auditors ein No-Go. Deswegen finden Sie dieses Konfigurationsszenario auch nicht in den Empfehlungen der SAP. Es kommt also ganz konkret auf die Situation an.

Ebenfalls sollte Ihnen auffallen, dass in den Konfigurationsempfehlungen der SAP nur solche Konfigurationen als sicher gelten, welche entweder das herstellereigene Verfahren WS-SecureConversation oder eine simple HTTPS Verschlüsselung verwenden. Eine Verschlüsselung lediglich auf Nachrichtenebene gilt als unzureichend, kann jedoch zusätzlich erfolgen.

Profilparameter zur Absicherung des SOAMANAGER

Zusätzlich zu den weiter oben geschilderten Überlegungen können Sie noch weitere Maßnahmen ergreifen, um Ihre Enterprise Services entsprechend abzusichern.

• wdisp/max_permitted_uri_len. Bestimmt die maximale Länge eine URL, die der Web Dispatcher entgegen nehmen kann. In einigen Angriffsszenarien wird über die URL ein Redirect über eine andere, sensible URL versucht, die ursprünglich seitens des Web Dispatchers gefiltert wird. Um hier auch in der letzten Verteidigungslinie eine Gegenmaßnahme bieten zu können, sollte die maximale Länge einer URL begrenzt werden. Der Standardwert von 2048 Zeichen kann hier beispielsweise auf 255 geändert werden. Vorsicht: Dieser Parameterwechsel muss getestet oder auf Basis der Zugriffs-Logs des Web Dispatchers bestätigt werden, um sicherzustellen, dass im Tagesbetrieb keine URLs höherer Länge benötigt werden.
• wdisp/max_uri_char_range. Bestimmt anhand der dezimalen Repräsentation eines ASCII-Zeichens die erlaubten Zeichen in einer URL. Beispiel: 37-127 entspricht den normalen alphanumerischen Zeichen auf der Tastatur. Um in der letzten Verteidigungslinie Angriffsszenarien über Sonderzeichen zu verhindern (um beispielsweise Kommentarzeichen für eine SQL-Injection zu inkludieren), sollten die erlaubten Zeichen beschränkt werden. Wenn zusätzlich das %-Zeichen verboten wird, verhindert man auch die URL-Kodierung von Sonderzeichen (Vorsicht: hier besteht Testbedarf).

• wdisp/max_url_map_entries. Bestimmt die maximale Anzahl von Einträgen in der URL-Mapping-Tabelle des SAP Web Dispatchers.
• wdisp/max_permission_table_size. Beschränkt die maximale Anzahl von Einträgen in der URI-Permission-Tabelle. Dies verhindert beispielsweise die Injection neuer Einträge in die Tabelle über beispielsweise gekaperte Cronjobs.
• wdisp/max_permission_table_entry_size. Bestimmt die maxiamle Anzahl von Zeichen in einem Eintrag in der Permission Tabelle des Web Dispatchers. Dies bildet eine zusätzliche Verteidigungslinie gegen Injections neuer Einträge in die Tabelle.
• wdisp/server_info_location. Angabe, woher der SAP Web Dispatcher die Information über die Applikationsserver bekommt, an die er die Web Requests verteilen kann. Der SAP Web Dispatcher bezieht seine Serverinformation vom Message-Server. Der Parameter gibt die (relative) URL an, wo diese Information im Message-Server steht. Sie können diese Information auch in einer Datei hinterlegen. In diesem Fall können Sie mit diesem Parameter den Dateipfad angeben, indem Sie ihn auf file://<path> setzen.

Steuerung des Zugriffs auf SICF-Knoten über den SAP Web Dispatcher

Über den SAP Web Dispatcher oder einen anderen Reverse Proxy Ihrer Wahl sollten Sie den Zugriff auf die einzenen Web Services sowie auf die Konfiguration des SOAMANAGER einschränken. Die einzelnen WSDL-Knoten finden Sie in der Regel unterhalb von /sap/bc/srt/wsdl.

Schränken Sie außerdem den Zugriff auf den SICF-Knoten /sap/bc/webdynpro/sap/appl_soap_management sowie auf /sap/admin ein.  Sie können den Zugriff beispielsweise auf den IP-Adressbereich Ihrer Administrator-Arbeitsplätze beschränken. Beachten Sie außerdem, dass über den Knoten /sap/bc/gui/sap/its/webgui ebenfalls ein Aufruf der Transaktion SOAMANAGER möglich ist.

Absicherung von ICF Knoten über das Berechtigungsobjekt S_ICF.

Zusätzlich zu einer Application Level Firewall (ALF) wie den SAP Web Dispatcher können Sie die einzelnen SICF-Knoten außerdem über das Berechtigungsobjekt S_ICF absichern. Hierbei konfigurieren Sie für einen bestimmten SICF-Knoten zunächst einen sogenannten „SAP Authorization String“, wie im Screenshot gezeigt.

Im Anschluss können Sie denn in einer Rolle das Berechtigungsobjekt S_ICF hinzufügen und dort das Feld ICF_FIELD mit diesem String befüllen. Damit genehmigen Sie den Zugriff auf genau diesen (und keinen anderen) SICF Knoten.

Rollen und Berechtigungen

Die folgende Tabelle zeigt eine offizielle Übersicht der SAP zu den verschiedenen Standard Rollen im Web Service Umfeld. Beachten Sie, dass der ABAP Service User in der Regel lediglich die Rolle
SAP_BC_WEBSERVICE_SERVICE_USER benötigt, keine andere.

Pflege der Tabelle HTTP_WHITELIST

Eine weitere Maßnahme ist die Pflege der Tabelle HTTP_WHITELIST. Diese fixiert URLs, die für eine Weiterleitung innerhlab einer WebDynpro ABAP bzw. Business Server Page (BSP) erlaubt sind. Beispielsweise könnte der Funktionsbaustein sap-exiturl beim Verlassen einer Stateful BSP genutzt werden, um eine entsprechende Weiterleitung auf einen Web Service auszuführen, der andernfalls nicht erreichbar wäre.

Um zu verhindern, dass die URL Filter des SAP Web Dispatcher durch eine Weiterleitung umgagngen werden, empfiehlt sich daher die Pflege einer Whitelist. Ein beispielhafter Eintrag würde wie folgt aussehen.

Protocol=https,host=nonprod.organisation.org,port=23443,url=/sap/redirects/*

In ihren eigenen ABAP-Entwicklungen können Sie die Tabelle HTTP_WHITELIST über den Funktionsbaustein CL_HTTP_UTILITY=>CHECK_HTTP_WHITELIST prüfen.

DaFRK

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

https://www.andreas-loibl.eu

Der Beitrag SOAMANAGER Security Settings | SAP Web Services absichern erschien zuerst auf DaFRK - Online Brainware for IT Professionals.

Demnach nutzen viele Kunden aus alten Zeiten noch den Workflow, dass Template-Rollen gebaut werden. Nach einer Änderung in dieser Template Rolle wird beim ersten Rollout diese in eine Kindrolle kopiert und angepasst. Später, wenn nachträgliche Änderungen am Template vorgenommen wurden und mehrere untergeordnete Rollen (Subordinate Roles) vorhanden sind, wird das Menü kopiert und die Rolle mit dem Expertenmodus neu generiert.

Das muss aber alles nicht sein, denn die SAP liefert im Standard den Workflow der abgeleiteten Rollen aus. Mit diesem Workflow ist es möglich, Eigenschaften einer übergeordneten Rolle (Superior Role) an mehrere untergeordneten Rollen (Subordinate Roles) zu vererben. Kunden setzen diesen Standard jedoch nicht um, weil sie häufig auf einige Hürden stoßen, die es zu überwinden gilt.

In diesem Beitrag werde ich einige der Fragen, die Kunden im Rahmen der Einführung eines Derived Roles Workflows haben, aufgreifen und versuchen zu beantworten. Dabei möchte ich zeigen, dass es keinen Grund für die Aufrechterhaltung eines umständlichen Copy-Paste-Szenarios mehr gibt.

SAP Rollenvererbung: Superior und Subordinate Role

Damit wir tiefer in das Thema einstiegen können, müssen wir erst einmal eine Template Rolle bzw. eine Superior Role erstellen und davon eine Kindrolle bzw. Subordinate Role ableiten. Danach werde ich aufzeigen, auf welche Probleme die Kunden zum ersten mal stoßen, wenn Sie diesen Ansatz selber versuchen.

 Das Konzept der abgeleiteten Rollen bzw. der Rollenvererbungshierarchien macht immer dann sinn, wenn

• mehrerere Rollen sich die gleichen Autorisierungsobjekte (Authorization Oobjects) teilen, oder
• sich in in den verschiedenen untergeordneten Rollen immer nur einzelne Feldwerte oder Organisationshierarchien (Organizational Levels) unterscheiden.

Übergeordnete Template Rolle für Ableitungskonzept

Einen solchen Fall wollen wir einmal nachstellen. Als aller erstes erstellen wir dazu eine Superior Role. Diese kann sozusagen als Eltern-Rolle angesehen werden und vererbt ihre Eigenschaften an alle untergeordneten Rollen. Dabei erstellen wir eine typische Rolle für den FI-Bereich

1. Wir fügen dazu zunächst im Reiter Menü einige Transaktionen hinzu
2. Im Reiter Autorisierung pflegen wir zunächst die sogenannten Vorschlagswerte. Um die Vorschlagswerte möglichst wenig anpassen zu müssen, können Sie die Standard Berechtigungsvorschlagswerte für eine Trnaskation in der SU24 anpassen.
3. Vorschlagswerte, die wir nicht übernehmen wollen, setzen wir auf inaktiv und kopieren sie. Wir bearbeiten dann die Feldausprägungen der kopierten Vorschlagswerte. Dadurch verhindern wir, dass beim Entfernen und erneuten Hinzufügen einer Transkation im Reiter „Menü“ Vorschlagswerte wieder hinzu kommen, ohne dass wir davon Kenntnis nehmen. Dies führt in der Praxis häufig zu versehentlich zu großzügig vergebenen Berechtigungen. Wir wollen vermeiden, dass Berechtigungsobjekte in unserer Rolle den Verarbeitungsstatus „Manuell“ bekommen. Dies ist ein Hinweis auf nicht ordnungsgemäß gepflegte Rollen.
4. Pflegen Sie alle Felder, die in den Kindrollen gleich ausgeprägt sein sollen, so dass diese den Status „gepflegt“ bzw. „Maintained“ erhalten. Alle Felder, die in den Kindrollen unterschiedliche ausgeprägt werden sollen, wie etwa der Verantwortungsbereich (RESPAREA), lassen wir ungepflegt (Status gelb)
5. Pflegen Sie die Organisationsebenen (engl.: Organizational Levels). Organisationsebenen, die in allen Subordinate Rollen gleich sein sollen, können Sie bereits in der Superior Role pflegen. Organisationsebenen, die sich in den Ableitungsrollen unterscheiden sollen, können Sie mit einer Tilde (~) belegen.

Anlegen einer Ableitungsrolle (Derived Role)

Im nächsten Schritt legen wir nun eine Ableitungsrolle (engl.: Derived Role) an. Im Einstiegsbildschirm geben Sie dann im Feld „Ableiten von“ (engl.: Derive From) den Namen der Master Rolle an. Speichern Sie die soebene angelegte Subordinate Role.

Wenn Sie sich jetzt die abgeleitete Rolle ansehen, werden Sie feststellen, dass derzeit nur das Menü, aber nicht der Pflegestatus der einzelnen Berechtigungsobjekte, geerbt wurde. Alle Felder haben den Vorschlagswert ihrer Transaktion, aber nicht den Pflegestatus aus der Superior Role. Auch die Organisationsebenen wurden nicht geerbt.

Im nächsten Schritt wollen wir nun die Organisationsebenen, die in der Master Role gepflegt wurden, sowie den Pflegestatus der Berechtigungsobjekte, vererben. Begeben Sie sich dazu in die Template Rolle und dort in den Reiter Berechtigungen (engl.: Authorizations) und dort in den Änderungsmodus der Berechtigungsdaten. Wählen Sie nun im Menü nach Berechtigungen -> Abgeleitete anpassen -> Abgeleitete Rollen generieren (engl. Authorizations -> Adjust derived -> Generate derived roles).

Wenn Sie sich nun wieder in die Derived Role begeben, werden Sie feststellen, dass nun sowohl der Pflegestatus der einzelnen Berechtigungsobjekte, als auch die einzelnen Organisationsebenen geändert wurden.

Wichtiger Hinweis: Die Organisationsebenen werden nur von der Master Role geerbt, solange die Organisationsebenen in der Derived Role noch nicht explizit gepflegt wurden.  Nachdem Sie die Organisationsebene der Ableitungsrollen einmal anfassen, werden Änderungen an den Organisationsebenen des Templates nicht mehr runter vererbt. Dies entspricht dem gewollten Verhalten im Standard (SAP Note 314513).

Änderung in Master Role überschreibt Derived Role

Kommen wir nun zu unserem nächsten Problem. In unserem Beispiel haben wir eine Rolle erstellt, welche das Berechtigungsobjekt K_ORDER enthält. Dieses Berechtigungsfeld enthält wiederum das Feld RESPAREA, welches den Verantwortlichkeitsbereich steuert.

Im Rahmen unseres Ableitungskonzeptes möchten wir, dass in den einzelnen Subordinate Rollen dieser Verantwortlichkeitsbereich unterschiedlich ist. Wir wollen immer noch, dass Änderungen in der Master Rolle an die abgeleitete Role vererbt werden, wollen aber den in der Subordinate Rolle gepflegten Verantwortungsbereich erhalten. Dadurch wollen wir sicher stellen, dass wir beim Ändern der Master Rolle nicht die Verantwortungsbereiche aller abgeleiteten Rollen händisch nachpflegen müssen. An dieser Stelle werden Kunden häufig frustriert und fallen wieder auf ihre alten Gewohnheiten der Rollenkopie zurück.

Genau dieses Problem können Sie jedoch aktuell herstellen. Ändern Sie dazu etwas am Master Template, indem Sie beispielsweise im Reiter Menü eine neue Transaktion hinzufügen. Generieren Sie im Anschluss die von dieser Rolle abgeleiteten Rollen. Wie Sie sehen, wird der ungepflegte Zustand im Feld RESPAREA des Berechtigungsobjektes K_ORDER übernommen. Sie müssten nun den Verantwortungsbereich erneut pflegen.

Anhebung eines Berechtigungsfeldes zur Organisationsebene

Eine Möglichkeit zur Lösung dieses Problems ist die Anhebung des Berechtigungsfeldes RESPAREA zur Organisationsebene.  In diesem Fall pflegen Sie nun die Verantwortungsbereiche als Organizational Level. Dies ermöglicht es Ihnen, Menüänderungen in der Hauptrolle vorzunehmen und den Verwantwortungsbereich individuell für die Abgeleiteten Rollen konsistent zu pflegen.

Jedoch sollten Sie diesen Schritt nicht allzu leichtfertig vornehmen, denn er hat die folgenden Konsequenzen:

• Wenn Sie ein Feld zur Organisationsebene anheben, wirkt sich dies auf alle Berechtigungsobjekte aus, welche dieses Berechtigungsfeld enthalten.
• Dadurch hat diese Aktion automatisch eine Auswirkung auf nicht nur diese Rolle, sondern auf alle Rollen mit diesem Berechtigungsfeld

Auswirkungsanalyse der Überführung in die Organisationsebene

Um die Auswirkungen dieses Schrittes festzustellen, muss deshalb eine kurze Auswirkungsanalyse durchgeführt werden. Zunächst sollten Sie feststellen, in welchen Berechtigungsobjekten das betroffene Berechtigungsfeld RESPAREA vorkommt. Dazu können Sie die Transaktion S_BCE_68001413 (Authorization BOjects by Complex Selection Criteria) verwenden. Geben Sie in das Feld den Namen des Berechtigungsfeldes ein – in unserem Fall RESPAREA. Sie erhalten eine Liste mit allen Berechtigungsobjekten.

Im nächsten Schritt ermitteln Sie, in welchen Transaktionen die betroffenen Berechtigungsobjekte in den Berechtigungsvorschlagswerten enthalten sind. Dies können Sie in der Tabelle USOBX_C tun. Damit diese Analyse ein möglichst aussagefähiges Ergebnis liefert, sollten die Berechtigungsvorschlagswerte in Ihrem System gut gepflegt sein (SU24). Geben Sie in der SE16 im Feld OBJECT den Namen des Berechtigungsobjekts und im Feld OKFLAG ein „Y“ ein. Führen Sie die Analyse auf die Tabelle aus.

Um nun zu guter letzt noch heraus zu finden, in welchen Rollen Berechtigungsobjekte mit dem Feld RESPAREA vorhanden sind, können Sie in der Transkation SE16 die Tabelle AGR_1251 analysieren. Geben Sie dort in das Feld „FIELD“ den Namen des Berechtigungsfeldes, in unserem Fall RESPAREA, ein. Um die Anzeige gelöschter Objekte zu unterdrücken, setzen Sie im Feld „DELETED“ ein “ ungleich X“. Führen Sie die Analyse aus.

Nicht nur erhalten Sie eine Liste aller Rollen mit dem Berechtigungsfeld, sondern auch die Ausprägung des Feldes in diesen Rollen. Dadurch können Sie sehr zuverlässig analysieren, welchen Pflegeaufwand Sie durch die Anpassung der einzelnen Feldausprägungen haben. Ist es vielleicht sogar akzeptabel, dass  das Feld RESPAREA in der Master Role gepflegt wird, weil es in den meisten Rollen gleich ausgeprägt ist und daher in der Superior Role vielleicht sogar vorbelegt werden kann?

Vorarbeiten für vor der Konvertierung des Berechtigungsfeldes

Wenn Sie sich anhand der Auswirkungsanalyse für eine Anhebung des Berechtigungsfeldes zur Organisationsebene entschieden haben, gilt es die technischen Voraussetzungen zu prüfen. Grundsätzlich können Sie  alle Berechtigungsfelder zur Organisationsebene anheben, außer die in SAP Hinweis 727536 unter Frage 1 genannten. Wenn Sie auf den Bedarf stoßen, eines der in Frage 1 genannten Felder vererben zu wollen, lesen Sie den alternativen Lösungsansatz weiter unten.

Viele Berechtigungsfelder erfordern technische Basis Vorarbeiten, bevor diese zu einer Organisationsebene angehoben werden können. Im Falle des Feldes RESPAREA müssen etwa die SAP Hinweise 698401 und 565436 beachtet werden. Dabei gibt es Unterschiede, je nachdem ob Sie die Elevation über PFCG_ORGFIELD_CREATE oder über Transkation SUPO (siehe unten) durchführen wollen.

Bevor Sie die Autorisierungsfelder einer Rolle zur Organisationsebene anheben, sollten Sie einen Transport dieser Rollen und der entsprechenden Standardwerte aus der SU25 erstellen. Folgen Sie dazu den Anweisungen aus SAP Hinweis 727536, Frage 5.

Anhebung eines Feldes zur Organisationsebene

Nachdem Sie die Vorarbeiten für das Berechtigungsfeld durchgeführt haben, können Sie es mit einem Report zur Organisationsebene anheben.

• Für Releases <750 verwenden Sie den Report 
   PFCG_ORGFIELD_CREATE (SAP Note 727536)
• Für Releases >=750 verwenden Sie die Transaktion SUPO (SAP Note 
  2625102)

Tragen Sie den Namen des zu konvertierenden Feldes ein. Wenn Sie den Report im Testmodus ausführen, erhalten Sie zunächst eine Übersicht über alle betroffenen Rollen und die darin vorgenommenen Änderungen.

Das Berechtigungsfeld selbst ist weiterhin in den betroffenen Berechtigungsfeldern enthalten. Nun enthält dieses Feld jedoch nicht mehr einen konkreten Wert, sondern einen Verweise auf die Organisationsebene, der in unserem Beispiel $RESPAREA genannt wird.

Bei der Ausführung des Reports kann es beim Übertrag des Feldwertes im Berechtigungsobjekt zur Organisationsebene der Rolle zu logischen Abweichungen kommen. Das ist deswegen so, weil eine Organisationsbene nicht die selben Werte entgegen nimmt wie ein Berechtigungsfeld. Diese Vorkommnisse werden im Ergebnisbereicht des Reports gelb dargestellt. Die so erfassten Rollen werden für die generierung in der Transaktion SUPC vorgesehen.

Wichtiger Hinweis: Dieser Report ist mandantenbezogen und muss daher in jedem Mandanten ausgeführt werden. Das initiale Anheben der Berechtigungsfelder muss jedoch im Entwicklungsmandanten der Systemlinie geschehen (siehe SAP Note 727536, Frage 10).

Wenn Sie den Report PFCG_ORGFIELD_CREATE verwenden, sollten Sie außerdem folgende Troubleshooting Notes berücksichtigen und auf Relevanz prüfen:

• 826871 (SAP_BASIS 700 SP00)
• 604787 (SAP_BASIS <=620)
• 532695 (SAP_BASIS <=620)
• 754836 (SAP_BASIS <=640)
• 724896 (SAP_BASIS <=640)
• 1336674 (SAP_BASIS <=711)
• 1247245(SAP_BASIS <=711, mit Nacharbeiten)
• 323817 (SAP_BASIS <=711)
• 1539557 (SAP_BASIS <=730)
• 1502568 (SAP_BASIS <=730)
• 1549101 (SAP_BASIS <=730)
• 1564573 (SAP_BASIS <=730)
• 1752992 (SAP_BASIS <=731)
• 1739055
• 2707782 (SAP_BASIS 731-750)
• 1624104 (sehr wichtig, mit Nacharbeiten, SAP_BASIS <=731)
• 2366702 (releaseunabhängig, bei Fehlermeldung „Locked by User“) + 
  2555130
• 1572774 + 1473306 (SEM-BW <=634)
• 1785259 (SEM-BW <=746)
• 2238411 (SAP_BW 750 mit BPC)
• 1659154 + 1866958 + 1660168 (GRCFND_A V1000, V1100, V8000)
• 2358446 (GRCPIERP V1000_700 & V1100_700)

Wenn Sie die Transaktion SUPO verwenden, beachten Sie die folgenden Notes:

• 1627197 (SAP_BASIS 750-752)
• 2535602
• 2166856
• 2505291
• 2697721

beachten Sie übergreifend außerdem die Restriktionen von SAP Note  410993 sowie
2067400.

Pflege von Organisationsebenen nach der Anhebung

Nachdem Sie das Berechtigungsfeld zur Organisationsebene angehoben haben, müssen Sie es in den einzelnen Rollen eventuell nachpflegen. Das Berechtigungsfeld RESPAREA ist ein sehr gutes Beispiel dafür. Denn im SAP-Standard kann ein Verantwortungsbereich unterschiedliche Elemente umfassen. Ein Verantwortungsbereich kann demnach auf folgende Elemente beziehen.

• eine Kostenstellengruppe
• eine Kostenstelle oder Kostenstellenstandardhierarchieknoten
• einen Auftrag
• einen Geschäftsprozess oder Geschäftsprozessknoten
• ein Profit-Center oder einen Profit-Center-Knoten

Um diese Logik nun auch in der Organsationsebene abdecken zu können, bekommen Sie zur Pflege der Organisationsebene „Verantwortungsbereich“ eine Mehrfachselektion mit unterschiedlichen Reitern.

Beachten Sie, dass es zu Inkonsistenzen im Mapping zwischen Organisationsebenen und Berechtigungsfeldern geben kann, wenn Sie Rollen aus einem anderen System importieren bzw. hochladen. In diesem Fall müssen Sie vorgehen wir in SAP Note 727536, Frage 21 beschrieben.

Upgrade und Einspielen von Support Packages

Für Berechtigungsfelder haben Sie ursprünglich die Schritte 1 und 2a der Transaktion SU25 verwendet, müssen Sie für die Übernahme neuer Vorschlagswerte in den Organisationsebenen den Report PFCG_ORGFIELD_UPGRADE bemühen (nur wenn Sie PFCG_ORGFIELD_CREATE verwenden. Bei Verwendung der Transaktion SUPO finden Sie die Funktionalität dort integriert) und diesen einmal pro relevanter Organisationsebene im Entwicklungsmandanten ausführen (siehe SAP Note 727536, Frage 11).

Ein zur Organisationsebene angehobenes Berechtigungsfeld wieder rückgängig machen

Sollten Sie sich umentschieden haben und es für besser erachten, eine Organisationsebene wieder als Berechtigungsfeld abzubilden, können Sie dazu den Report PFCG_ORGFIELD_DELETE verwenden.

Dabei werden jedoch nicht die zuvor gepflegten Berechtigungsfeldwerte oder die Werte der Organisationsebene übernommen, sondern lediglich die Standardpflege wiederhergestellt. Es handelt sich dabei also um eine verlustbehaftete Wiederherstellung des Ursprungszustandes. Um einen Datenverlust zu vermeiden, können Sie vor der erstmaligen Umstellung über PFCG_ORGFIELD_CREATE einen Sicherungstransport der Rollen und der SU25 Werte exportieren.

Andere Lösungsmöglichkeit über Sammelrollen

Selbstverständlich können Sie das oben genannte Problem der überschriebenen Feldausprägungen in den Derived Roles auch lösen, ohne das Berechtigungsfeld auf eine Organisationsebene zu heben. In diesem alternativen Lösungsweg setzen Sie in der Hauptrolle das Berechtigungsfeld auf inaktiv, also Status gelb. Unterschied: Vorhin haben wir das zu vererbende Feld ungepflegt, also auf Status gelb, gelassen

Zusätzlich zu der Hauptrolle erstellen Sie die Ableitungsrollen sowie sogenannte Addon Rollen (auch Exception Roles genannt). Diese Exception Roles enthalten dann einzig und allein das Berechtigungsfeld mit den gewünschten Feldwerten. 

Zu guter letzt erstellen Sie eine Sammelrolle (Composite Role), in welcher Sie die Ableitungsrolle + die Exception Role mit dem gewünschten Verantwortungsbereich reinpacken. Diese Sammelrolle weisen Sie letztendlich den einzelnen Usern zu.

Dieser Lösungsansatz ist außerdem Pflicht, wenn Sie für verschiedene Organisationseinheiten in den Ableitungsrollen unterschiedliche Aktivitätsfelder pflegen wollen. Wie bereits erwähnt können bestimmte Felder, darunter das Berechtigungsfeld ACTVT, nicht auf Organisationsebene angehoben werden. Wenn Sie also beispielsweise folgendes realisieren wollen

• Bestimmte Benutzer sollen in den Buchungskreisen 610 und 620 lesen, aber nicht verändern oder löschen dürfen
• Sie sollen in einem anderen Buchungskreis (630 z. B.) hingegen alles dürfen

Dann bleibt Ihnen nichts Anderes übrig, als diese Aktivitäten in verschiedene Exception Roles auszulagern und den Benutzern die Template Rolle plus die jeweiligen Exception Rollen individuell bzw. über eine Sammelrolle zuzuweisen.

Diese Lösung ist außerdem empfehlenswert, wenn Sie den Lösungsansatz über die Organisationshierarchien als zu kompliziert ansehen und möglichst wenig in den Standard eingreifen wollen.

Bereits bestehendes Eltern-Kind-Rollensystem migrieren

Sie haben bereits, wie mein Kunde, ein Rollen-System, und wollen dieses nun in das Master-Derived Role Konzept überführen? Dann müssen Sie in diesem Schritt heraus finden, welche Unterschiede es zwischen der Master und der Derived Role gibt.

Nur so können Sie wissen, welche Berechtigungsfelder und Organisationsebenenfelder Sie ohne Weiteres vererben und welche Sie dann im Anschluss manuell nachpflegen müssen. Hierzu können Sie die Transaktion S_BCE_68001777 verwenden.

DaFRK

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

https://www.andreas-loibl.eu

Der Beitrag SAP Abgeleitete Rollen | Derived Roles | Rollenvererbung erschien zuerst auf DaFRK - Online Brainware for IT Professionals.

Da macht es natürlich Sinn, dass man diesen zentralen Ansprechpartner auch möglichst einfach konsumieren kann. Das ist in der Geschäftswelt nichts neues. Wenn ich Daten brauche, will ich sie mir komfortabel auf unterschiedliche Art und Weise holen können. Zu diesem Zweck hat der Hersteller die neue SAP User Experience (SAP UX) definiert. Im Endeffekt handelt es sich dabei um einige Guidelines zur Gestaltung von Frontendelementen unter Einsatz von Webtechnologien. Die User Experience kann dabei jedoch auf unterschiedliche Art und Weise hergestellt werden.

Die offensichtlichste Variante ist die Erstellung einer Fiori App unter Verwendung von SAPUI5. Dabei bedienen Sie sich explizit den über 200 vordefinierten UI Controls aus dem SAPUI5 Framework. Da diese vom Hersteller SAP vordesignt sind, ist die Compliance zu den Design Guidelines der SAP User Experience entsprechend einfach. Der Nachteil dabei: Sie haben in der Regel auch entsprechend wenig Eingriffsmöglichkeit in diesen Standard. Grundsätzlich können Sie zwar unter SAPUI5 eigene Custom UI Controls entwickeln, dies ist jedoch im Vergleich zu den Templating Funktionalitäten von beispielsweise AngularJS alles andere als komfortabel.

Worum soll es jetzt in diesem Beitrag genau gehen? Wir durchleuchten zusammen, wann man in seinem Webtechnologieprojekt im SAP-Umfeld auf das klassische SAPUI5 setzen sollte und wann man ein mächtigeres Frontend SDK wie Angular verwendet. Die Begründungen hierzu leite ich über eine Zurschaustellung der einzelnen Vor- und Nachteile ab. Als Inhaber eines Webmasters Europe Diploma in Web-Engineering aus dem Jahre 2014 komme ich ursprünglich aus der von SAP losgelösten Webentwicklung.

Der SAPUI5 Bär im SAP Umfeld

Hierbei habe ich  damals mit Laravel mein erstes eigenes CMS mit den typischen Komponenten (User- und Berechtigungsverwaltung, Texteditor, Mediendatenbank, Social Media Integration) aufgebaut. Später, als ich in die SAP Beratung gewechselt bin, habe ich mir mit der SAP HANA Express Edition die einzelnen Möglichkeiten für einen Bring Your Own Language Ansatz zum Entwickeln von Webapplikationen auf Basis von SAP HANA angesehen. Das ganze ist im Endeffekt ganz einfach, weil die SAP alle nötigen Infos dazu bietet.

Ein Kunde hat nach einem Entwickler gefragt, der eine strategische Entscheidungshilfe zur Frage klassische Frontend SDKs gegenüber SAPUI5 bieten kann. Der Kunde wollte ein komplexes Shopsystem zum Verkauf von digitalen Dienstleistungen bauen, dessen Preise sich dynamisch auf Basis von Echtzeitanalysen berechnet werden. Viele der Daten kommen aus der SAP-Welt. Bei Workshops diverser SAP Beratungshäuser wurde dem Kunden immer wieder der SAPUI5 Bär aufgebunden, obwohl der Kunde traditionell klassische Webentwickler im Hause und dort sein größtes Know How hat. Dabei fiel auf, dass die Partner außerhalb von SAPUI5 häufig nicht auf Ebene des Kunden kommunizieren konnten, da Sie kein Know How in der klassischen Webentwicklung mitbringen. Das Drängen der Partner auf SAPUI5 wirkte „aus der Not heraus verargumentiert“, dementsprechend gering war auch das Vertrauen in die Technologie.

Dem Kunden wurde auch erzählt, dass er SAPUI5 einsetzen muss, wenn er seinen Code in der SAP Cloud Plattform ausführen möchte, weil man dort nur SAPUI5 Projekte erstellen könnte. Dem ist nicht so. Sogar von der SAP selbst kommt ein Tutorial zum Erstellen eines Angular Bootstraps in der WebIDE. Dabei erstellt man zunächst über das Menü ein neues SAPUI5 Projekt, löscht im Anschlus sämtliche Files, und befüllt seinen Projektordner wie in einem klassischen Angular Projekt.

Dabei bin ich persönlich zum Schluss gekommen, dass sich für große monolithische Webprojekte mächtige Frontend-Frameworks wie Angular2 besser eignen als das klassische SAPUI5. Warum das so ist, werde ich in den folgenden Kapiteln erläutern. Übrigens: Auch klassische Backend Sprachen wie PHP und Python und dort verbreitete Frameworks wie Laravel und Django haben unter SAP HANA ihre Daseinsberechtigung.  In Zukunft wird es für die verschiedenen Approaches auch Beiträge geben. Mit diesem Beitrag möchte ich insbesondere verhindern, dass sich Kunden beim Versuch, ein komplexes Firmenportal mit SAPUI5 aufzubauen, verrennen. Aber auch wo SAPUI5 seine Glanzmomente hat, will ich Ihnen nicht verschweigen.

Was spricht für Angular und React

Es gibt einige Argumente, die dafür sprechen, anstelle von SAPUI5 lieber die monolithischen Frameworks Angular2 und ReactJS zu verwenden. Ich werde Ihnen im Folgenden erläutern, warum ich diese Meinung vertrete und versuche immer konkrete Beispiele anzubringen. Keine Sorge, auch die Vorteile von SAPUI5 werden wir ansprechen. Diese bekommen einen extra Abschnitt, bevor wir am Ende zu einer Schlussfolgerung kommen.

Templating

Unter SAPUI5 generieren Sie UI Controls über programmeigene Methoden, was beispielsweise wie folgt aussieht. In folgendem Coding erzeugen wir ein div, fügen diesem eine CSS-Klasse hinzu und fügen innerhalb dieses divs einige vordefinierte Controls ein.

renderer : function (oRM, oControl) {
	oRM.write("<div");
	oRM.writeControlData(oControl);
	oRM.addClass("beitragsbewertung");
	oRM.writeClasses();
	oRM.write(">");
	oRM.renderControl(oControl.getAggregation("_rating"));
	oRM.renderControl(oControl.getAggregation("_label"));
	oRM.renderControl(oControl.getAggregation("_button"));
	oRM.write("</div>");
}

Wie Sie sehen, ist diese Form der UI-Erstellung nicht nur umständlich, sondern auch schlecht lesbar. Im Vergleich dazu ist ein Template unter Angular2 im Wesentlichen der pure HTML-Code mit einigen zusätzlichen Controls für das Einfügen von JavaScript-Actions. ReactJS ist hier wieder eine andere Geschichte, denn React nutzt für das Templating den XML-Jargon XSL. Sie können sich jedoch sehr einfach vorstellen, dass ein puristisches Template unter Angular2

• schneller aufgebaut wird, da der Browser den direkten Code ohne Objektzugriff einliest
• leichter lesbar und erweiterbar ist
• einfacher innerhalb des Templates selbst auf Subtemplates durchgegriffen werden kann – so können Sie etwa innerhalb des divs ein weiteres Subtemplate aufrufen.
• innerhalb des Templates sehr leicht Datenbankwerte einfügen können. So können Sie in einem Angular2 Template jederzeit eine beliebige von Ihnen erstellte Datenmanagementmethode aufrufen
• in der Regel zu einer besseren Suchmaschinenoptimierung führt, weil individuelle Attribute (etwa rel nofollow Attribute) für die einzelnen zu rendernden Controls individueller definiert werden können

Verstehen Sie mich nicht falsch. SAPUI5 ist, genau wie Angular auch, lediglich ein Framework. Sie können jederzeit mit JavaScript Ihre eigenen Methoden definieren und diese verwenden. Natürlich sollte aber der Sinn des Frameworks sein, von Hause aus Best Practices anzubieten und eben dem Entwickler den Aufbau einer Templating Engine ersparen. Die besten Frameworks bieten einen optimierten Weg, etwas zu tun, ohne den Entwickler in seinen Freiheiten einzuschränken.

Isomorphie und Performance

Unter Isomorphie versteht man die Aufteilung des JavaScript-Codes in eine server- und eine client-seitige Ausführungsschicht. Allein schon aus Sicherheitsgründen müssen bestimmte Teile des Codings auf Serverebene ablaufen. Denn auf Clientseite hat der Browser und somit der Besucher Eingriffsmöglichkeit in das Coding – und kann somit die Geschäftslogik zu seinen Gunsten beeinflussen. Server seitiges Rendering hat des Weiteren Vorteile in der Performance und in der Suchmaschinenoptimierung. Zum einen müssen die auf den Server ausgelagerten Coding Teile nicht erst vom Client heruntergeladen werden. Zum Anderen kann der Server beispielsweise Caching Engines verwenden, um einen Objekt-Cache wie Redis oder einen Key-Value-Cache wie beispielsweise memcached aufzubauen.

Auf der anderen Seite müssen zwangsläufig einige Teile des JavaScript-Codings auf Clientseite erledigt werden. Dies sind in der Regel all jene Bestandteile, welche den DOM im Browser des Anwenders beeinflussen wollen, also in der Regel mit dem Design, der Animation, Usability und der allgemeinen Bedienung zu tun haben. Diese Bestandteile können selbstverständlich nur auf Clientseite beeinflusst werden.

Während beispielsweise unter Angular in Verbindungs mit Node.js die Aufteilung des Codings feingranular erfolgen kann, ist diese Aufteilung unter SAPUI5 vorgegeben. Große Teile des Codings laufen auf Clientseite. Die ist aber aus Sicherheitsgründen kein Problem, weil der Zugriff aufs Backend in der klassischen SAPUI5-Architektur aufgetrennt ist. Nicht umsonst gibt es bei einer Fiori App in der Regel eine Backend- und eine davon abgetrennte Frontend-Komponente. Aber die Entwicklung ist in ihrer Freiheit stark eingeschränkt. Es ist äußerst umständlich und teilweise auch unmöglich, gezielt einzelne Verarbeitungsschritte von der Clientseite auf die Serverseite zu holen. Dementsprechend schwer wird auch die Nutzung von Caching Engines. Dies macht sich aus meiner Erfahrung auch spürbar im Performance-Vergleich zwischen einer Angular- und einer SAPUI5-App bemerkbar.

Code Splitting und Hot Page Reloading

Auch beim Bundling macht sich dies bemerkbar. Unter Bundling versteht man die Zusammenführung von Coding in verschiedenen Dateien zu einem einzelnen File. Der Browser des Benutzers muss nur noch lediglich eine .js-Datei herunterladen anstatt mehrerer. Dadurch reduziert sich die Anzahl der HTTP Requests. Beispiel anhand eines konkreten Codings

// app.js
import { add } from './math.js';

console.log(add(16, 26)); // 42
// math.js
export function add(a, b) {
return a + b;
}

Das aus diesen beiden Dateien zusammengefügte Coding würde wie folgt aussehen.

function add(a, b) {
return a + b;
}

console.log(add(16, 26)); // 42

Sowohl Angular als auch React nutzen intelligente Code Splitting Engines wie Webpack oder Browserify. Diese bieten in der Regel eine State of the Art Experience. Dazu gehört beispielsweise die Möglichkeit zum Hot Page Reloading. Während beim Live Reloading beim Abändern einer .js-Datei die ganze Seite neu geladen werden muss und der Status der App mit den aktuell gespeicherten Variablen verloren geht, wird beim Hot Page Reloading nur der Code der geänderten Files neu reingeladen und der Status der App geht nicht verloren. Dies erlaubt auch in der Produktion durchdachte Live Deployments von neuem Coding und ist ein wichtiger Bestandteil moderner DevOps Strategien. Diese Technologie wird deshalb nicht umsonst von vielen großen Technologie-Unternehmen verwendet. Unter SAPUI5 schauen Sie hier ins Leere. Sie verändern etwas in Ihrem Projekt? Die ganze App bitte einmal neu laden.

Meiner Erfahrung nach bietet SAPUI5 an dieser Stelle bei weitem nicht die selben Möglichkeiten. Dies stellt aus meiner Sicht ein wichtiges Argument dar, warum Sie große monolithische Webanwendungen nicht mit SAPUI5 realisieren sollten.

Transpiler Support und ES6

Wie Sie vielleicht wissen, wird standardisiertes JavaScript als ECMAScript bezeichnet. 2015 und 2016 gab es hier die letzte große Veränderung mit der Einführung von ECMAScript 6 (ES6) und ECMAScript 7 (ES7). ECMAScript ist ein Standard, JavasScript ist ein Dialekt basierend auf diesem Standard. Von JavaScript selbst gibt es wiederum weitere Dialekte, beispielsweise CoffeeScript oder TypeScript. Mit der Einführung von ES6 haben diese Dialekte jedoch an Bedeutung verloren. Zum Vergleich zwischen ES6- und ES5-konformem JavaScript ein Beispiel, welches den Aufbau einer Klasse erläutert.

// ES6
class Shape {
constructor() {}
draw() {}
}
class Circle extends Shape {
draw() {
super.draw();
...
}
}
// ES5
var Shape = function() {...};
Shape.prototype.draw = function() {...};
...

Sie sehen also, ES6 führt beispielsweise das sogenannte class Keyword ein und ermöglicht somit einen State of the Art Klassenaufbau im Vergleich zum älteren ES5-Standard. Wenn Ihr Business Erfahrungen bzw. Bedarfe hat, ES6-konformen Code zu schreiben, müssen Sie sich unter SAPUI5 erstmal ins Zeug legen. SAPUI5 nutzt die ES6 Best Practices bis heute nicht zur Genüge. Teilweise muss SAPUI5 mit Hilfe externer Bibliotheken erst „enabled“ werden. Ein Kommentar von einem Github User zu diesem Thema:

Hey guys, I really think support for modern build frameworks should be built right into the OpenUI5 framework. As it is, it looks quite „old-fashioned“ to an experienced JS developer. You would push adoption in the broader community much further if you adopted the latest toolsets more quickly. Just a suggestion. – derwaldgeist, Github

Unter react und Angular2 können Sie Ihren Code sowohl ES6-konform als auch in anderen Javascript-Dialekten wie beispielsweise CoffeeScript oder TypeScript verfassen. Der integrierte Transpiler kümmert sich um die Übersetzung des Codes in Plain JavaScript und abstrahiert daher diese Ebene vom Entwickler. Klarer Punkt für react und Angular.

Native Mobile Entwicklung

Unter Native Mobile Entwicklung versteht man die Entwicklung einer klassischen Smartdevice App, die auf einem der großen Smart Device Betriebssysteme wie Android oder iOS läuft. Eine native Mobile App ist hierbei in der Regel in einer höheren Programmiersprache wie Objective-C, Java oder im Falle von iOS in Swift geschrieben. Wie einfach ist es für einen Entwickler unter SAPUI5, reactJS und Angular2, auch eine solche Native Mobile App zu entwickeln? Wir reden hier nicht über eine sogenannte Hybrid App, in welcher die eigentliche Webanwendung innerhalb einer minimalistischen Wrapper App geladen wird. Aufgrund der besseren User Experience und der höheren Mächtigkeit einer Native App – insbesondere im Zugriff auf Hardware-Funktionalitäten – haben viele Projekte die Anforderungen nach einer Native Mobile App.

Grundsätzlich muss man sagen: In allen drei Sprachen ist es möglich, die gleiche User Experience wie in der Webanwendung auch in eine Native Mobile App zu gießen. Die SAP liefert hierzu das SAP iOS SDK  sowie eine Referenz-App aus. Der Aufbau geht relativ leicht von der Hand, jedoch gelten bei diesem SDK beinahe die selben Einschränkungen wie beim eigentlichen SAPUI5. Und damit wären wir wieder beim Problem.

Unter reactJS können Sie mit React Native auf Ihrer bestehenden Webanwendung aufbauen und somit beinahe der selben Mächtigkeit und Flexibilität eine Native Mobile App erzeugen. Unter Angular2 können Sie neben React Native auch Ionic oder NativeScript verwenden. Sie haben also den Vorteil einer Hybrid App in dem Sinne, dass Sie sehr einfach auf Ihrer bestehenden Webanwendung aufbauen können. Gleichzeitig hat Ihre App aber die volle Mächtigkeit einer Native Mobile App.

Was spricht für SAPUI5

Nun gibt es aber auch Argumente für SAPUI5. Die Technologie ist nicht umsonst genau für eine einheitliche Web User Experience im SAP-Umfeld geschaffen worden. Es gibt einige Argumente für SAPUI5, die ich an dieser Stelle natürlich nicht verschweigen möchte.

Security

Eins steht einmal fest: Sowohl unter SAPUI5 als auch unter react und Angular fahren Sie aus Security Sicht immer besser, als wenn Sie komplett von der Pike auf selber in puristischem JavaScript programmieren. Alle drei Frameworks bringen bereits eine ins Framework eingebaute Verteidigungslinie gegen Cross Site Scripting (XSS) Angriffe mit. Diese Schicht müssten Sie ansonsten selbst implementieren und pflegen.

SAPUI5 bietet an dieser Stelle etwas mehr als die Konkurrenz. Zum einen bringt das Framework eine integrierte Schutzkomponente gegen Clickjacking mit. Clickjacking ist eine beinahe schon lächerlich einfache Angriffsform, bei welcher der Benutzer denkt, auf eine Schaltfläche auf der Seite zu klicken, in Wahrheit aber auf ein iframe-Element einer fremden Seite (z. B. Paypal) klickt. SAPUI5 bietet eine integrierte Möglichkeit, Trusted Domains zu pflegen, um eingebettete Seiten zu filtern. Diese Filterfunktion muss in den anderen Frameworks erst manuell im Code oder auf Webserverebene implementiert werden.

Des Weiteren bietet SAPUI5 ein integriertes URL Whitelisting für Eingabeelemente. Alle Eingabeelemente unterhalb von sap.ui.richttexteditor.RichTextEditor und the sap.ui.core.HTML sind demnach dazu in der Lage, die Eingabe von nicht erlaubten URLs zu verhindern. Das eignet sich beispielsweise um zu verhindern, dass Anwender einer SAPUI5 Anwendung Links zu schadhaften Domains setzen oder Eigenwerbung betreiben. In den anderen Frameworks muss eine solche Funktionalität erst implementiert werden.

SAPUI5 bietet außerdem über das SAP NetWeaver Gateway einen integrierten Schutzmechanismus gegenüber Cross Site Request Forgery (CSRF) Attacken. Auf der anderen Seite bietet Angular2 bereits ebenfalls einen integrierten Support gegenüber XSSI und CSRF-Angriffe. Die HTTPClient Bibliothek von Angular entfernt sämtliche )]}‘,\n Zeichen aus Antworten beim Aufruf einer externen HTTP Schnittstelle und sendet zufällig generierte Authentication Cookies an den Client.

Theming

Im Gegensatz zu react und Angular bietet SAPUI5 eine integrierte Theming-Option. Theming ist nicht zu verwechseln mit Templating. Beim Theming geht es darum, einem geladenen Template abhängig vom ausgewählten „Thema“ ein anderes aussehen zu verleihen, beispielsweise die Farben oder Logos zu wechseln – oder der UI einen weihnachtlichen Look zu verleihen. Unter SAPUI5 können die einzelnen UI Controls je nach ausgewähltem Theme anders gerendert werden. Das Theme wird dabei über den UI Theme Designer bearbeitet und entworfen. In den anderen Frameworks sind Sie über den Einbau einer Theming-Bibliothek oder das Implementieren eigner Methoden selbst in der Pflicht, dem User eine Theming Option anzubieten.

SAP Fiori Design Guidelines

Das aller stärkste Argument für die Nutzung von SAPUI5 ist die simple Tatsache, dass jede der vordefinierten UI Controls die Anforderungen der SAP Fiori Design Guidelines erfüllt. Das betrifft nicht nur das Aussehen, sondern auch das Verhalten und die Interaktionsfähigkeit der Controls. Allein aus dieser Tatsache heraus empfiehlt es sich schon, bei allen Applikationen, die innerhalb von SAP bzw. mit dem Fiori Launchpad verwendet werden sollen, SAPUI5 zu verwenden. Nur so gewährleisten Sie ein einheitliches Look & Feel beim Arbeiten im SAP Frontend.

Umso umständlicher wird es hingegen jedoch, wenn Sie unter SAPUI5 ein von den Fiori Design Guidelines abweichendes Design herstellen wollen. Hierbei müssen Sie entweder die bestehenden UI Controls kopieren und abändern oder direkt in den Cascading Style Sheet eingreifen. Da geht das Design von eigenen UI Controls mit React und Angular natürlich schon wesentlich einfacher.

Vordefinierte UI Controls

In diesem Zuge muss ich natürlich auch erwähnen, dass SAPUI5 mehr als 200 vordefinierte UI Controls mitbringt, die sich out of the box in der eigenen App verwenden lassen. Diese Vielzahl an UI Controls manuell von einem Frontend Design Team entwickeln zu lassen, kostet natürlich einiges an Mannstunden. Unter der SAP Fiori Elements Bibliothek können Sie sich die Vielzahl der verfügbaren Conrols ansehen. Besonders beeindruckend finde ich die 3D Viewports sowie die Visualisierungswerkzeuge im Analytics Bereich. Hier scheint SAP Fiori und bringt seine Stärken so richtig zum Vorschein.

Dieser enorme Vorteil von SAPUI5 lässt sich ein wenig abschwächen in dem Sinne, dass natürlich auch unter Angular und React externe JavaScript Bibliotheken mit vorgefertigten UI Controls importiert werden können. Eine Bibliothek, deren UI Controls ein sehr ähnliches Aussehen wie die SAP Fiori Elements aufweisen, ist die Kendo UI. Der Link liefert Ihnen eine Liste aller UI Controls unter Kendo, die Sie sich bei Gelegenheit zu Gemüte führen und mit den SAP Fiori Elements vergleichen können. Obwohl Kendo UI ursprünglich als eigenständiges SDK gedacht war, lässt es sich mittlerweile auch zum Großteil in Angular einhaken und verwenden. Neben Kendo UI gibt es natürlich noch andere Bibliotheken, die sich in Angular integrieren lassen und vordefinierte UI Controls mitliefern.

Personalisierung von Apps

Ein großer Vorteil von SAPUI5 ist die bereits integrierte Möglichkeit zur Personalisierung von Apps. Benutzer können Datenfelder von Apps ausblenden oder in anderen Gruppen einordnen und gruppieren. Hier ist der Link zur SAP Fiori UI adaption at Runtime in der SAP Library. Das Video zeigt die Prozedur im Detail.

Eine solche Funktionalität vorimplementiert zu haben, ist natürlich sehr durchdacht und würde bei Eigenentwicklung einige Mannstunden verschlingen. Unter SAPUI5 bekommt man die Funktionalität out of the box. Das ist ein großer Pluspunkt für SAPUI5, wenn es um die wiederkehrende, bestenfalls tägliche Nutzung von kleinen Appliaktionen geht.

Fazit

Kommen wir nun zum Schluss. Wann sollten Sie nun SAPUI5 verwenden, und wann ein dediziertes Javascript SDK wie Angular? In aller letzter Instanz entscheiden das natürlich Sie als Kunde. Es kommt schließlich auch darauf an, wo Ihre Stärken liegen und wo Sie Know How im Hause haben. Grundsätzlich können Sie jedes Projekt mit beiden Technologien realisieren. Der Aufwand unterscheidet sich nur. Es gibt aus meiner Sicht einige Indikatoren dafür, wann Sie SAPUI5 verwenden sollten und wann nicht. Die Grafik zeigt meine Schlussfolgerung in einer Übersicht.

Das ganze jetzt noch einmal textlich aufbereitet in Tabellenform

DaFRK

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

https://www.andreas-loibl.eu

Der Beitrag SAP Fiori UX | SAPUI5 vs ReactJS oder AngularJS mit KendoUI erschien zuerst auf DaFRK - Online Brainware for IT Professionals.

Was sind Transport Based Correction Instructions (TCIs)?

Bei den TCI handelt es sich im Wesentlichen um eine Unterkategorie der SAP Hinweise, die ich in einem früheren Beitrag bereits schon einmal erklärt habe. SAP Hinweise bestehen im Wesentlichen aus Korrekturanweisungen (englisch: Correction Instructions). Diese lassen sich unterteilen in automatische und manuelle Korrekturanleitungen.

Die automatischen Korrekturanleitungen kann man sich sehr einfach vorstellen, wenn man schon einmal mit einer Versionsverwaltung wie Git oder Subversion oder dem Linux-Kommandozeilentool patch gearbeitet hat. Die alte und die neue Version eines Stück ABAP Codings werden analysiert. Die Unterschiede von der alten zur neuen Version werden als ein sogenannter Änderungsvektor festgehalten. Dabei handelt es sich im wesentlichen um eine Information, welche Zeilen aus dem alten Coding gelöscht werden und zwischen welchen Zeilen neues Coding eingefügt werden soll. Durch diesen Änderungsvektor lassen sich also Coding-Änderungen automatisiert einspielen.

Andere Änderungen an DDIC-Objekten können hingegen oft nur manuell eingespielt werden. Das sind sogenannte manuelle Korrekturanleitungen. Um diese zu implementieren, muss der einspielende Benutzer im SAP System die DDIC Objekte manuell bearbeiten. Zumindest im ersten System einer Systemlinie. Für die Folgesysteme können die manuellen Änderungen als Transport erfasst und durchtransportiert werden.

Und genau diesen Ansatz hat sich der Hersteller nun zu Herzen genommen. Warum nicht diese manuellen Änderungen nicht gleich in einem Transport vorbereiten und dem Kunden zur Verfügung stellen? Dies würde dem Kunden die manuellen Tätigkeiten ersparen. Dadurch reduziert sich gleichzeitig das Risiko, beim Einspielen der manuellen Korrekturanleitungen einen Fehler zu machen.

Nun, der Hersteller hatte dies anfangs nicht gemacht, weil Transporte im SAP-Umfeld bekanntermaßen abhängig von den darunterliegenden Softwarekomponenten sind. Ein Transport, welche in Support Package 02 funktioniert, ist unter Umständen mit Support Package 01 überhaupt nicht kompatibel.

Um diese Problematik zu lösen und trotzdem dem Kunden den Komfort eines vorbereiteten Transportes zu bieten, wurden die Transport Based Correction Instructions (TCI) eingeführt. Dabei handelt es sich im Endeffekt um eine SAP Note, welche für jede von diesem Hinweis betroffene Softwarekomponente einen kleinen Transport bereitstellt. Und zwar für jeden relevanten Support Package Stand. Detaillierte Informationen zu TCIs sind in SAP Hinweis 2576306 zu recherchieren.

Den SAP Note Assistant für TCI vorbereiten

Damit der SAP Note Assistant mit transportbasierten Korrekturanleitungen umgehen kann, muss diese Funktionalität implementiert werden. Folgende Voraussetzungen sind dafür notwendig:

• Einen Benutzer mit der Rolle SAP_OCS_STD (kompletter SPAM Zugriff) oder SAP_OCS_TCI_IMPORT (nur TCI)
• Support Package Manager (SPAM) in der Version 70 oder neuer. Erst mit SPAM 70 können Sie die Bootstrapping Note in der Systemlinie durchtransportieren. Mit SPAM 69 oder älter müssen Sie die Enablement Note in jedem System manuell einspielen. Ein Transport der Enablement Note, die mit SPAM 69 oder älter eingespielt wurde, führt zu Systemfehlern.
• Implementieren der TCI Enablement Note und je nach SAP_BASIS Release einige Vorgänger-Hinweise.
• Einen der folgenden gelisteten SAP NetWeaver Releases oder neuer
  • SAP NetWeaver 7.00 SP09
  • SAP NetWeaver 7.01 SP05
  • SAP NetWeaver 7.02 SP06
  • SAP NetWeaver 7.31 SP01
  • SAP NetWeaver 7.40 SP02
  • SAP NetWeaver >= 7.50 SP00

Während die Aktualisierung der SPAM Komponentenversion und die Aktualisierung des NetWeaver SP-Stacks ein No-Brainer ist, müssen wir uns ein wenig über die TCI Enablement Note unterhalten. Zunächst einmal ist es nicht immer nötig, die Enablement Note einzuspielen. Die Implementierung ist nur nötig, wenn die Softwarekomponenten SAP_BASIS in den folgenden Support Package Stacks steckt.

Befindet sich der Support Package Stack Ihrer SAP_BASIS Version über dem „Max. SP Stack“ dieser Tabelle, ist Ihr SAP Note Assistant bereits TCI-fähig. Ein Einspielen der Enablement Note entfällt in diesem Fall. Befindet sich die SAP_BASIS Komponente unterhalb des „Min. SP Stack“, ist TCI noch gar nicht unterstützt und Sie müssen einen höheren Support Package Stack anstreben.

Einspielen der TCI Enablement Note

Wenn Sie zu den Unglücklichen gehören, welche die TCI Enablement Note noch einspielen müssen, habe ich hier eine entsprechende Kurzanleitung für Sie zusammengestellt. Zunächst einmal sollten Sie wissen, dass es zur Implementierung der Enablement Note je nach SAP_BASIS Release unterschiedliche Implementierungshinweise gibt. Sie werden im Zentralhinweis 2187425 gesammelt. In dieser Note ist auch eine PDF-Datei, die in Kapitel 1.5 einige Vorgänger-Hinweise listet, die zuvor eingespielt werden müssen.

Die einzelnen Note Assistant Boot Strapping Notes leiten demnach:

• Für SAP BASIS 700 – SAP Note 2446868
• Für SAP BASIS 701,702 –  SAP Note 2444141
• Für SAP BASIS 731 aufwärts –  SAP Note 1995550

Die Prozedur ist dabei bei allen Hinweisen ähnlich. Öffnen Sie die für Ihren SAP_BASIS Release relevanten Hinweis und klicken Sie auf den Reiter „Correction Instruction“. Scrollen Sie nach unten und doppelklicken Sie auf die Softwarekomponente SAP_BASIS.

Wählen Sie im Folgefenster Ihren SAP_BASIS Release aus und downloaden Sie die entsprechende Correction Instruction hierzu. Sie erhalten eine .SAR-Datei.

Loggen Sie sich nun auf dem System, in welchem Sie das TCI Enablement implementieren wollen, im Mandant 000 ein. Rufen Sie die Transaktion SPAM auf und wählen Sie Support Package -> Load Packages -> From Frontend. Laden Sie die .SAR-Datei hoch. Sie haben das Support Package nun in den Support Package Manager hochgeladen. Jetzt müssen Sie es einspielen.

Zeigen Sie dazu in der Transaktion SPAM die „Neuen Support Packages“ an. Sie finden dort die Bootstrap SAP TCI Note wieder. Wählen Sie diese aus und wählen Sie den Button „Calculate Queue“. Sollten Sie hier die Meldung bekommen „Not allowed – Support Package ist already applied“, befindet sich die Note bereits in Ihrem aktuellen SAP_BASIS Support Package und die Implementierung der Note ist daher nicht nötig. Andernfalls importieren Sie nun die berechnete Queue, indem Sie in der Transaktion SPAM auf „Import Queue“ gehen.

Solle beim Import der Queue etwas fehlschlagen und die Transaktion SPAM im Status rot stehen bleiben, sollten Sie als aller erstes die Installation fortsetzen und die Queue somit neu anstarten. Dies ist ein bekanntes Problem bei der Implementierung des Support Packages in der Transaktion SPAM. Erst bei wiederkehrendem Fehler  befinden Sie sich wirklich in einer Ausnahmesituation.

Nach dem Import der Queue werden Sie feststellen, dass die SPAM Queue den Status gelb hat und als nächste Aktion die Implementierung der eigentlichen SAP Note, in unserem Beispiel 1995550, ist. Bestätigen Sie die SPAM Queue nicht manuell, um den Status der Queue auf grün zu bekommen, sondern spielen Sie stattdessen die Note ein. Das Einspielen des Hinweises wird die SPAM Queue automatisch bestätigen, sofern Ihr System mit dem SAP OSS Portal verbunden ist. Sollte dem nicht der Fall sein, müssen Sie die Queue nach Einspielen der SAP Note manuell bestätigen.

Zum Einspielen der Note begeben Sie sich in die Transaktion SNOTE und laden Sie die Note herunter. Spielen Sie im Anschluss die Note ein. Ist der Vorgnag erfolgreich, setzen Sie den Status des Hinweises auf „Completely Implemented“.

Hinweis: Wenn Sie eine veraltete SPAM Version genutzt haben und der Implementierungsstatus der Note nicht korrekt angezeigt wird, können Sie dies über SAP Hinweis 2345669 lösen.

Mit Abschluss dieses Schrittes ist Ihr SAP Note Assistant grundsätzlich TCI-fähig. Um jedoch die volle Funktionalität zu implementieren, müssen Sie noch die Rollback-Funktionalität implementieren.

Transport-based Correction Instructions Rollback implementieren

Nachdem Sie den SAP Note Assistant grundsätzlich TCI-fähig gemacht haben, sollten Sie noch die Rollback-Funktionalität implementieren. Diese erlaubt Ihnen das Zurücknehmen einer TCI unter bestimmten Voraussetzungen. Ein TCI hat Attribute, die seine Rollback-Fähigkeit anzeigen. Außerdem muss n der SPAM das „Backup Flag“ aktiviert sein. Dadurch weiß dann der Benutzer, ob ein Zurücknehmen der Correction Instruction möglich ist oder nicht. Ist das Zurücknehmen nicht möglich, sollten Sie vor der Implementierung ein Backup erstellen.

Um die Funktionalität zu implementieren, muss zunächst der TCI aus SAP Hinweis 2408383 und im Anschluss der Hinweis selbst eingespielt werden. Schlägt die Implementierung des Hinweis beim ersten Versuch mit der Meldung „LOAD_PROGRAM_INTF_MISMATCH“ fehl, handelt es sich hierbei um ein bekanntes Problem und die Implementierung sollte einfach wiederholt werden. Als Follow-Up müssen Sie zu guter letzt SAP Note 2643757 implementieren.

DaFRK

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

https://www.andreas-loibl.eu

Der Beitrag Transport Based Correction Instructions (TCI) erklärt erschien zuerst auf DaFRK - Online Brainware for IT Professionals.