SAP Unicode Conversion | Unicode Migration mit DMO

Obwohl nur noch sehr wenige SAP-Kunden Non-Unicode Systeme im Einsatz haben, hatte ich in letzter Zeit bei einigen Kunden mit der Problematik „Unicode Conversion“ zu tun. Im Zuge der S/4HANA Umstellung ziehen nun auch die letzten Kunden in die Unicode-Welt ein. Was es mit der Unicode-Zeichensatzkodierung auf sich hat, wie sie funktioniert und historisch gewachsen ist, das besprechen wir hier in diesem Beitrag. Um einen Mehrwert in Bezug auf die langfristige Planung einer S/4HANA Umstellung zu liefern, zeige ich die unterschiedlichen Upgrade-Pfade mit Unicode Conversion auf und liefere eine Entscheidungsmatrix. Auch beantworte ich, welche Auswirkungen die Unicode Umstellung auf das Sizing hat.

Geschichte der Zeichensatzkodierung

Ursprünglich waren Computer sehr langsam und hatten nur sehr wenig Arbeitsspeicher, der zudem auch noch sehr teuer war. Um deswegen Daten kostengünstig verarbeiten zu können, nutzte man in den frühen Computerzeiten sogenannte Lochkarten zur Verarbeitung. Die ersten Zeichensätze stammen genau aus diesen Zeiten der Lochkartenverarbeitung. Denn zu diesen Zeiten war es besonders wichtig, nur die nötigsten Zeichen innerhalb eines Zeichensatzes unterzubringen, um wertvolle Speicherressourcen zu sparen.

Wenn Sie auf der Tastatur den Buchstaben „A“ eingeben, übergeben Sie dem Computer in Wahrheit ein Binärnummer mit einer Länge von meist 8 Bit, also einem Byte. Der Computer schaut dann in der verwendeten Zeichensatztabelle nach einem Zeichen, das in dieser Tabelle die selbe Binärnummer aufweist. In einem arabischen Zeichensatz kriegen Sie beispielsweise das Zeichen • angezeigt, wenn Sie die der Zeichensatztabelle die Binärfolge unsers Buchstabens „A“ übergeben. Dieses Zeichen wird im Anschluss von einer Schriftartendatei (z. B. einer .ttf-Datei) abgefragt und dargestellt.

Wie viele Zeichen sind eigentlich für die Darstellung in verschiedenen Sprachen notwendig?

• Englisch: Ungefähr 60 Zeichen
• Alle westeuropäischen Sprachen: um die 300 Zeichen.
• Koreanisch: Ungefähr 12.000 Silben
• Chinesische Sprachen: Ungefähr 50.000 Zeichen.

Dies beinhaltet noch nicht rein wissenschaftliche Zeichen, die beispielsweise sprachübergreifend in der Mathematik genutzt werden. Sie sehen also: der Umfang ist durchaus erstaunlich. Genau aus diesem Grund hat man sich zur Anfangszeit der Textverarbeitung in Computersystemen auf den sogenannten ASCII-Zeichensatz konzentriert. Dieser umfasste 7 Bit und enthält damit ca. 128 Zeichen. Er ist dadurch dazu in der Lage, die meisten Zeichen für die Darstellung westeuropäischer Sprachen darzustellen – aber eben nicht alle. Dafür wären nämlich um die 300 Zeichen notwendig gewesen, was jedoch zwei zusätzliche Bits und damit einen höheren Speicherplatzverbrauch sowie eine längere Verarbeitungszeit pro Zeichen bedeutet hätte.

Die meisten Zeichensätze, die in den 70er und 80er Jahren veröffnetlicht wurden, waren Modifikationen und Erweiterungen des ASCII-Zeichensatzes. Viele von ihnen führten ein zusätzliches achtes Bit (also ein volles Byte) ein und waren somit dazu in der Lage, 256 Zeichen darzustellen. Da dies immer noch nicht für die 300 Zeichen des westeuropäischen Sprachraumes reicht, wurden teilweise Zeichen aus dem ASCII-Standardnamensraum entfernt, um Platz für länderspezifische Zeichen zu schaffen. Deswegen gab es so viele von diesen ASCII-Abkömmlingen. Die Gruppe dieser Zeichensätze werden aufgrund ihrer Eigenschaft, ein Byte pro Zeichen zu belegen, auch Single Byte Per Character (SBCS) Zeichensätze genannt.

Wie funktioniert Unicode?

Unicode oder genauer gesagt das Unicode Transformation Format (UTF) definiert keine Zeichen wie ein klassicher Zeichensatz, sondern Skripte.  Ein Skript ist eine Sammlung von Zeichen, die in mehreren Sprachen verwendet werden. Ein gutes Beispiel für ein Skript ist beispielsweise  das Latin Script ISO 8859-1. Ein Unicode-Zeichen besteht aus einer Bitfolge für das Zeichen und einer Bitfolge für das Skript, welches zu dessen Darstellung verwendet werden soll. Man bezeichnet UTF-8 daher nicht als einen Zeichensatz (eine Character Page), sondern als ein Encoding. Die hierzu benötigte Bit Größe variiert abhängig von der Unicode-Variante (UTF-8, UTF-16 oder UTF-32) und der Position des Zeichens in der Notation. Unter UTF-8 schwankt beispielsweise der Speicherplatz für ein Zeichen zwischen 1 und 4 Byte.

es gibt noch andere Unicode-Encodings, zum Beispiel gibt es UTF-8, UTF-16, UTF-32, CESU-8, UCS-2, UTF-32 und UCS-4. In der SAP Welt spielen jedoch standardmäßig nur UTF-8 und UTF-16 eine Rolle. Während in der darunterliegenden Datenbank des SAP-Systems häufig eine UTF-8 Kodierung verwendet wird, werden die Zeichen Anwendungsserver intern standardmäßig über eine UTF-16 Kodierung verarbeitet. Die folgende Tabelle zeigt ein Beispiel für die hexadezimale Darstellung unterschiedlicher Zeichen unter den verschiedenen Encodings.

Wir ersehen aus diser Tabelle, dass die Zeichen „A“ und „c“ unter UTF-8 lediglich ein Byte benötigen, das Zeichen „Ö“ zwei Byte und die verschiedenen Bullet-Symbole zwischen zwei und vier Byte. Woher weiß UTF-8 nun, wann ein neuer Buchstabe beginnt, und welche Bits noch zu einem Buchstaben gehören? Hierzubedient sich das System sogenannten Indikator-Bits. Ein Lead Byte Indicator zeigt an, dass ein neues Zeichen beginnt. Ein Trailing Byte Indicator zeigt an, dass ein Byte zum vorherigen Bit hinzugerechnet werden muss. Die folgende Tabelle zeigt die Prozedur. Sie zeigt den Lead Byte Indicator (rot) und den Trailing Byte Indicator (grün).

Das System erkennt also anhand der Trailing Byte Indikatoren, dass die drei Bytes zusammen gehören und ein Zeichen bilden. Danach werden die Byte Indikatoren entfernt und die Bits neu kombiniert. Daraus ergibt sich dann die sogenannte Byte Sequence für das entsprechende Zeichen in der Tabelle eines Skripts wie beispielswiese ISO-8859-1. Die Ergebnis Byte Sequence lautet AC 00. Das wäre auch gleichzeitig die Byte Sequence, die unter UTF-16 gespeichert werden würde. Sie sehen also: Für das Zeichen • mussten wir unter UTF-8 drei Bytes belegen und zur Ermittlung des Zeichens eine Berechnung durchführen.  UTF-8 speichert

• Standard ASCII-Zeichen in einem einzigen Byte (Single Byte)
• Akzentzeichen und Umlaute in zwei Bytes (Double Byte)
• klassischen Zwei-Byte-Text, also vor allen Dingen östliche Zeichensätze, in drei Bytes (Triple Byte) oder selten 4 Bytes.

Unter UTF-16 brauchen wir für jedes Zeichen nur zwei Bytes, da wir bereits das richtige Ergebnis gespeichert hatten. Warum verwendet man dann nicht einfach immer UTF-16? Nun, weil UTF-16 IMMER zwei Byte belegt. Während es unter UTF-8 beispielsweise reicht, für den Buchstaben „A“ nur ein Byte mit hexadezimal „41“ zu belegen, muss man unter UTF-16 ein Byte mit „00“ und ein zweites mit „41“ speichern. Allgemein kann man sagen, dass sich UTF-8 bei westlichen Zeichensätzen besser auszahlt, während UTF-16 bei asiatischen Zeichensätzen besser geeignet ist.

Wie funktionierte Mehrsprachensupport vor Unicode?

Eine Code Page, also ein Zeichensatz, kann man sich als eine Tabelle von Zeichen vorstellen. Eine Byte Sequenz korrespondiert dabei immer zu einem Zeichen. Man unterscheidet sogenannte Single Byte Code Pages, in denen ein Byte immer einem Zeichen entspricht, und Double Byte Code Pages, in denen immer jeweils zwei Byte einem Zeichen ensprechen. SAP unterstützt derzeit die folgenden Sprachen. Das Venn-Diagramm stammt vom Hersteller selbst und zeigt gleichzeitig die möglichen Sprachkombinationen der damaligen Welt an.

In dieser Zeit arbeitete SAP mit Standard Zeichensätzen wie etwa dem Latin Script. Diese bildeten dabei eine Vielzahl von Sprachen ab. Ein Beispiel

Blended Code Pages im SAP System

Kunden standen früher einige Tricks zur Verfügung, um ihre eigenen Sprachkombinationen innerhalb eines SAP Systems zu unterstützen. Eine solche LÖsung waren die sogenannten Blended Coge Pages. Dabei handelt es sich um Zeichensätze, die aus Zeichen mehrerer Standard-Zeichensätze bestehen. Der Kunde konnte also zusagen seinen eigenen Zeichensatz erstellen. Logischerweise wurden hierbei jedoch nur einige der Zeichen aus den Standard Code Pages übernommen, einige mussten weichen. Auch der Hersteller SAP lieferte einige dieser Blended Code Pages aus. Einige vom Hersteller angebotene Blended Code Pages waren beispielsweise

Multi-Display / Multi-Processing (MDMP)

Eine erweiterte Form der Blended Code Pages ist das MDMP Verfahren. MDMP erlaubt es dem System, dynamisch den Zeichensatz auf dem Anwendungsserver zu wechseln. Es können also mehrere Standard Code Pages auf einem System genutzt werden. Bei diesem Verfahren bestimmt die Anmeldesprache des Benutzers, welchen Zeichensatz das System lädt. Wenn eine Blended Code Page nicht alle benötigten Sprachen abdecken konnte, haben viele Kunden dies in der Vergangenheit mit MDMP gelöst. Bei MDMP wird dem Benutzer abhängig von seiner Anmeldesprache eine Code Page zugewiesen.  Bei uns in Deutschland war die Verwendung sehr beliebt, wenn die Sprachen Deutsch und Japanisch unterstützt werden sollten. Deutsche Benutzer haben dann die Code Page 1100 (ISO8559-1) bekommen und japanische Benutzer die Code Page 8000 (Shift JSIS). Wenn sich nun auch noch englische Benutzer im System anmelden wollten, haben sich die Kunden häufig durch das Erstellen einer kundeneigenen Sprache geholfen. Damit gab es dann eine Anmeldesprache Englisch, welcher die Code Page 1100 zugewiesen wurde, und eine Anmeldesprache Englisch, welcher die Code Page 8000 zugewiesen wurde. Somit konnten englische User sowohl deutsche als auch japanische Zeichen sehen, wenn sie sich mit der jeweiligen Sprache angemeldet hatten.

Wenn Sie von einem MDMP System auf Unicode konvertieren wollen, empfiehlt der Hersteller SAP ein Involvement des herstellereigenen SAP Service in das Projekt. Bei einigen Quell-Releases ist dieses Involvement sogar Pflicht. Für Details konsultieren Sie SAP Hinweis 548016.

Sie finden raus, ob Ihr Non-Unicode System MDMP nutzt, indem Sie in der SE16 die tabelle TCPDB prüfen. Enthält diese Tabelle lediglich einen Eintrag, befinden Sie sich in einem Single Code Page System. Enthält die Tabelle mehrere Zeilen, handelt es sich um ein MDMP System. Über den Report RSCPINST können Sie nun im Anschluss prüfen, ob Ihr SAP System Unambiguous oder Ambiguous Blended Code Pages nutzt. Der Report spcukt Ihnen alle auf dem System installierten Sprachen und die von diesen genutzte Code Page aus. Wenn alle installierten Sprachen die selbe Code Page nutzen, haben Sie ein Single Code Page System. Ist dem nicht so und Sie können ein MDMP-System bereits ausschließen, müssen Sie nun prüfen, ob Sie Unambiguous oder Ambiguous Blended Code Pages verwenden.

Liste der Unambiguous Blended Code Pages in SAP

Liste der Ambiguous Blended Code Pages unter SAP

Nun haben Sie volle Klarheit über die Konfiguration Ihres Non-Unicode Systems erlangt.

Datenkorruption bei Falschverwendung

Wenn man als SAP-Benutzer auf die Idee kommt, die Zeichensatz- und Schriftarteinstellungen zu manipulieren, kann man im SAP Gui Bildschirm Zeichen eingeben, die nicht in der Code Page des Awnendungsservers hinterlegt sind. Das Problem hierbei: Auch wenn Sie beispielsweise als Deutscher Nutzer japanische Zeichen im Frontend eingeben, heißt das noch lange nicht, dass diese auch so in der Datenbank gespeichert werden. In der Regel machen Sie damit alles nur schlimmer, weil es dabei zur Korruption dieses Datenbankobjektes kommen kann.

Um dies zu verhindern, golt in einem SAP Non-Unicode System grundsätzlich:

• Es dürfen nur Zeichen einegeben werden, welche in den 7-Bit ASCII Zeichensatz oder in die lokale Codepage der Anmeldesprache fallen
• Benutzer, die Batchprozesse ausführen, müssen mit der korrekten Anmeldesprache angemeldet werden
• EBCDIC Zeichensätze werden nicht unterstützt.

Warum benötigen SAP Kunden heutzutage ein Unicode System?

Die offensichtlichste Aussage für die meisten Kunden ist: Sie brauchen ein Unicode-System, um auf S/4HANA migrieren zu können. Da das klassische SAP ERP 6.0 bzw. SAP ECC im Jahr 2025 ausläuft, ist also eine Unicode Conversion die erste Vorbereitung für die Transition. Neben diesem derzeit sehr brennenden Grund gibt es allerdings auch noch andere Gründe, die für eine Unicode-Umstellung sprechen. Zum einen können nun die Benutzer  ohne lästige Workarounds (Z-Sprachen, Blended Code Pages, MDMP Zuweisung von Code Pages abhängig von der Anmeldesprache) die Zeichen anderer Sprachen betrachten. Viele Standard Code Pages haben desweiteren keine Sonderzeichen wie etwa das Copyright oder das Trademark Symbol, weil sie zu stark mit den länderspezifischen Akzentzeichen befüllt sind.

Andere Gründe sind beispielsweise die Unterstützung von XML, .NET und Java. Mit vielen Standard Code Pages ist die Unterstützung von XML und Java nicht möglich, da die dort benötigten Sonderzeichen nicht in der Code Page abgebildet sind. Java und .NET sprechen nur Unicode. Möchte sich ein ABAP Stack mit einem Java Stack unterhalten, kann man zwar eine Zeichentabellenkonvertierung über den Java Connector (JCo) durchführen, jedoch gibt es hierbei bekannte Probleme (SAP note 975768). Probleme bereitet auf Non-Unicode auch der Austausch von SOAP-Nachrichten (SAP Note 1358929). Zudem sprechen Nebensysteme, mit denen man beispielsweise über Webschnittstellen oder RFC kommuniziert, bereits Unicode. Um hier alle Zeichen des Gesprächspartners interpreiteren zu können, empfiehlt sich entsprechend ein Unicode-System.

Unicode-enablement von ABAP Programmen

Wenn Sie auf Unicode umstellen, wird im dreischichtigen SAP-Systems nicht überall die gleiche Kodierung verwendet. Während die Datenbank und der Software-Client SAP Logon standardmäßig UTF-8 verwenden, werden Zeichen innerhalb des Anwendungsservers im Format UTF-16 behandelt. Damit das funktioniert, muss nicht nur das SAP System an sich durch eine Unicode Conversion gegangen sein, sondern auch das ausführende ABAP-Programm muss Unicode-enabled werden.

Sie können auf einem Unicode System kein ABAP Programm ausführen, welches das Unicode-Flag nicht gesetzt hat. Sie können jedoch umgekehrt das Flag bereits auf Ihrem Non-Unicode System setzen und das Programm weiterhin dort nutzen. Es macht also Sinn, die ABAP Programme vor der Unicode Conversion zu aktivieren. Sie können das Flag automatisiert über den Report UCCHECK setzen lassen, oder aber auch manuell über die Transkationen SE38, SE24 usw.

Warum muss man ein ABAP Programm Unciode-enablen? Weil die Verarbeitung von UTF-16 Zeichen 30% mehr RAM-Speicher und CPU-Zeit benötigt als die Verarbeitung einer Standard Non-Unicode Page. Genau aus diesem Grund sind geschriebene ABAP-Programme auf einem Non-Unicode System standardmäßig nicht Unicode-enabled.

Datenbankwachstum bei einer Unicode Conversion

Als groben Richtwert für das Datenbankwachstum nach einer Unicode Migration eines SAP Systems kann man von Bereichen zwischen 35 und 60% Wachstum ausgehen. Der Minimalwert tritt vor allen Dingen dann ein, wenn in der Datenbank größtenteils nur ASCII-Zeichen gespeichert sind, der Maximalert, wenn in der Datenbank viele fernöstliche und wissenschaftliche Zeichen gespeichert sind.

Für eine Konvertierung nach UTF-8 gilt: ASCII-Zeichen verursachen keinen Anstieg des Speicherplatzes. ISO-8859-1 Zeichen wie beispielsweise deutsche Umlaute verursachen einen leichten Anstieg im einstelligen Prozentbereich. Chinesische, japanische und koreanische Zeichen brauchen nach der Konvertierung im Schnitt 50% mehr Speicherplatz, griechische und kyrillische Zeichen 100% mehr.

Für eine Konvertierung nach UTF-16 gilt: Chinesische, japanische und koreanische Zeichen brauchen nicht mehr Speicherplatz wie vor der Konvertierung. Dafür brauchen ASCII, ISO-8559-1, griechische und kyrillische Zeichen jeweils doppelt so viel Speicherplatz, also Anstieg um 100%.

Das ist das Wachstum nach der Konvertierung. Wie sieht es nun mit dem Wachstum nach der Konvertierung, also im laufenden Betrieb, aus? Wenn Sie beispielsweise vor der Unicode-Migration noch kein japanisch unterstützt haben, fragen Sie sich vielleicht, ob Ihre Datenbank nun rapide wachsen wird, weil Sie nun japanische Anwender auf Ihr System lassen. In dieser Hinsicht kann ich Sie aber beruhigen. Grund hierfür ist die Tatsache, dass fernöstliche Sprachen häufig Silbensprachen sind. Das Wort „Thunder“ braucht beispielsweise auf einer Standard Code Page 8 Byte Speicher. Im japanischen ist dieses Wort nur ein einziges Zeichen, welches mit 3 Byte gespeichert werden kann. Westliche Sprachen brauchen für den selben Text mehr Speicher als eine Silbensprache. Sie sehen also: Das Problem des Datenbankwachstum ist nicht die Nutzung fernöstlicher Sprachen, sondern einfach nur die technische Konvertierung einer Standard Code Page in den Unicode-Standard.

Die CPU-Anforderungen steigen nach einer Unicode-Conversion um ca. 30-35% für die Verarbeitung von ASCII-Zeichen. Bei Double-Byte Zeichen wie etwa japanisch, chinesisch und koreanisch gibt es eien minimalen Anstieg von weniger als 5%. Die Hauptspeicheranforderungen steigen abhängig von der darunterliegenden Zieldatenbank um ca. 50%. Das gilt selbstverständlich nicht für SAP HANA, da hier andere Regeln gelten. Für HANA muss ein dediziertes Sizing durchgeführt werden. Die Netzwerkbandbreite wird bei ASCII-Zeichen mit 7% mehr belastet, japanische Zeichen benötigen 15% mehr Bandbreite, alle anderen asiatischen Sprachen benötigen 25% mehr Bandbreite im Netzwerk.

Konfiguration von RFC-Verbindungen zwischen Unicode und Non Unicode Systemen

Bei der Kommunikation zwischen Unicode und Non Unicode Systemen muss eine Konvertierung von Zeichen geschehen, um sicher zu stellen, dass beide Systeme möglichst viele gemeinsame Zeichen miteinander austauschen können. Hierbei müssen Sie beim Einrichten der RFC-Verbindung angeben, ob das Zielsystem ein Non-Unicode System ist und falls ja, ob MDMP aktiv ist oder nicht. Für Zeichen, die nicht konvertiert werden können, wird ein sogenannter Error Indicator gesetzt. Dieser ist standardmäßig auf das Raute-Symbol gesetzt (#), kann jedoch von Ihnen umkonfiguriert werden.

Die folgende Abbildung zeigt die Zusammenhänge bei der heterogenen Kommunikation auf. Daraus gehen folgende Ergebnisse hervor:

• Das Unicode SAP System kann ohne Probleme alle Zeichen der Non-Unicode Systeme empfangen – egal welche Code Page diese benutzen und ob sie MDMP nutzen odernicht
• Ein Non-Unicode System kann nur die Zeichen von einem anderen SAP-System lesen, welche auch in ihrer Code Page sind. So kann das Non-Unicode System mit JSIS Code Page auch alle Zeichen einer RFC-Verbindung lesen, die von einem anderen System mit JSIS-Kodierung kommen. Wenn dieses System jedoch beispielsweise ein MDMP System ist und daher die Zeichen auch mit einer anderen Code Page kodieren kann (in unserem Beispiel Latin-1), können hier nicht alle Zeichen empfangen werden.

Bei der Kommunkation zwischen Unicode und Non-Unicode kümmert sich das Unicode-System darum, die Unicode-Zeichen in die Code Page des anderen Systems zu konvertieren. Wenn ein MDMP-System die Code Page des anderen Non-Unicode Systems kennt, versucht es die Zeichen der fremden Code Page in die Code Page des Empfängersystems zu konvertieren, so weit möglich. Das ist natürlich nur bei Zeichen möglich, die in beiden Code Pages vorhanden sind.

Voraussetzungen für eine Unicode Conversion

Unicode wird grundsätzlich ab SAP Basis 6.20 unterstützt und sollte daher für die meisten Kunden kein Problem mehr sein. Auch ein Single Code Page System, egal ob Standard oder Unambiguous Blended Code Page) kann ohne Probleme auf Unicode angehoben werden. MDMP Systeme können zwar auch angehoben werden, benötigen jedoch eine spezielle Vorbereitung. Da eine Unicode Conversion auf einer hterogenen Systemkopie basiert, muss das System auf der Zielplattform weiterhin unterstützt werden. Um eine Unicode Conversion durchzuführen, müssen Sie traditionell bereits auf R/3 Enterprise 4.7 (hat heutzutage keine Bedeutung mehr) oder neuer aktualisiert haben. Welche Basis Releases Sie brauchen, um von bestimmten Konstellationen (beispielsweise ERP 2004 + MDMP) auf Unicode zu kommen, können Sie SAP Hinweis 548016 entnehmen. Wennn Sie die Human Resource Funktionalität in Ihrem ERP System nutzen, ist außerdem SAP Note 573044 für Sie relevant. Für die Systemvoraussetzungen einer Unicode Conversion unter SAP BW 3.1 oder höher konsultieren Sie SAP Note 543715.

Je nachdem, welches Szenario auf Sie zutrifft, sind unterschiedliche SAP Hiwneise für Sie relevant. Zentrale Anlaufstelle für jegliche Form von Unicode Conversions ist SAP Hinweis 551344. Von dort werden Sie bei auf die unterschiedlichen Notes der verschiedenen Szenarien verwiesen.

• Standalone Unicode Conversion eines Single Code Page Systems: SAP Hinweis 1051576
• Standalone Unicode Conversion eines Ambiguous Blended Code Page oder eines MDMP Systems: SAP Hinweis 551344.
• Kombinierte Unicode Conversion und Upgrade eines MDMP Systems mit einem Zwilling (SAP_BASIS < 46C oder SAP_BASIS = 610): Twin Upgrade and Unicode Conversion (TUUC): SAP Hinweis 959698
• Combined Upgrade und Unicode Conversion eines Ambiguous oder Unambiguous Blended Code Page Systems oder eines MDMP Systems (SAP_BASIS >=4.6C und SAP_BASIS != 6.10): SAP Hinweis 928729
• Update, Datenbankmigration und Unicode Conversion über die Database Migration Option (SAP_BASIS >=4.6C SP62 bis 7.40, aber ungleich 6.20): SAP Note 1968505.

Wenn Sie diese SAP Hinweise studieren, werden Sie merken, dass Ihnen nicht immer alle Szenarien zur Verfügung stehen. Beispiel: Eine CUUC können Sie nur machen, wenn Ihr SAP_BASIS Release >= 4.6C, aber ungleich 6.10 ist. Für SAP Basis älter 4.6C und für SAP_BASIS 610 steht Ihnen als Ausweichlösung die Twin Upgrade & Unicode Conversion (TUUC) zur Verfügung.

Wichtiger Hinweis: der Unicode Conversion Guide, den die SAP als PDF ausliefert, ist nur gültig für die Konvertierung von MDMP und Ambiguous Blended Code Page Systemen. Für die Konvertierung eines Single Code Page Systems hat der Unicode Conversion Guide keine Aussagekraft! Dies geht aus SAP Note 551344 hervor.

Unicode Planung für die System Conversion nach S/4

Wie oben bereits erwähnt, ist eine Unicode Conversion erst ab R/3 4.7 bzw. ab SAP ECC 5.0 möglich. Ein Upgrade auf ein Release unterhalb von ECC 6.0 ist heutzutage ohnehin nicht mehr möglich, so dass diese Releases heutzutage keine Bedeutung mehr in der Planung haben. Klassischerweise führte man zuerst das Upgrade auf ECC 6.0 und im Anschluss daran die eigentliche Unicode Conversion durch. Durch dieses Combined Upgrade and Unicode Conversion (CUUC) Verfahren können Sie beide Schritte miteinander verbinden und müssen sich daher nur um eine einzige Downtime kümmern. Die CUUC nimmt jedoch keine Datenbankmigration vor, beispielsweise von AnyDB nach SAP HANA. Dafür gibt es als dritte Option die eierlegende Wollmilchsau, die Databsae Migration Option (DMO). Mit der DMO können Sie ein Upgrade, einen Datenbankwechsel und gleichzeitig eine Unicode Conversion in einem Schritt durchführen.

Diese Option steht Ihnen jedoch nur zur Verfügung, wenn Ihr Non-Unicode System als Single Code Page System konfiguriert ist, und Ihr Quellrelease >=SAP ECC 5.0. Ambiguous Blended Code Page oder MDMP Systeme können die DMO nicht verwenden, genau so wenig SAP Systeme mit Release R/3 4.7c und älter. Außerdem können Sie eine Unicode Conversion innerhalb einer DMO nur für ein Zielrelease unter NetWeaver 7.40 ausgeführt werden. Die Twin Upgrade & Unicode Conversion (TUUC) wird nur in Ausnahemfällen vorgenommen.

Bevor Sie fragen: Es ist nicht geplant und wahrscheinlich in Zukunft auch nicht möglich, eine 1-Step Migration direkt von einem Non-Unicode System auf S/4HANA zu implementieren. Grund hierfür ist, dass für SAP S/4HANA Unicode eine absolute Grundvoraussetzung darstellt. Wir beschäftigen uns jetzt mit den verschiedenen Heransgehensweisen: Wie kombinieren Sie sinnvoll eine Unicode Conversion mit einer System Conversion nach SAP S/4HANA? Die Abbildung soll hierbei eine Hilfe zur Entscheidungsfindung sein.

Wenn Ihr Quellrelease R/3 4.7c und älter ist, empfehle ich Ihnen, wie aus der Grafik ersichtlich, keinen Zwischenschritt auf Business Suite on HANA. Sie müssen nämlich mit Release R/3 4.7c und älter erst über den Software Update Manager ein Upgrade auf ECC 6.0 EHP7 vornehmen und im Anschluss daran nochmal eine Migration über den Software Provisioning Manager (SWPM). Sie sollten stattdessen einfach nur das Uprade auf ECC 6.0 EHP7 machen und von dort ohne weiteren Zwischenschritt die System Conversion nach SAP S/4HANA Enterprise Management.