SAP Unicode Conversion | Unicode Migration mit DMO

(Last Updated On: 19. November 2018)

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.

ZeichenUTF-8UCS-2UTF-16
A4100410041
c6300630063
ÖC3 B600F600F6
DA 6406640664
E4 BA 7598759875
F0 9D 84 9EN/AD834 DD1E

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).

HEXEAB080
BIN111010101011000010000000
Remove Lead Bits 1010110000000000
Neu Gruppieren1010110000000000
ErgebnisAC00
Zeichen  

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

CodepageUnterstütze SprachenDouble Byte?
ISO8859-1Dänisch, Niederländisch, Englisch, Finnisch, Französisch, Deutsch, Italienisch, Isländisch, Norewgisch, Protugiesisch, Spanisch, Schwedisch
ISO8859-2Kroatisch, Tschechisch, Englisch, Deutsch, Ungarisch, POlnisch, Rumänisch, Slowakisch, Slowenisch
ISO8859-5Englisch, Russisch
ISO8859-6Arabisch, Englisch
ISO8859-7Englisch, Griechisch
ISO8859-8Englisch, Hebräisch
ISO8859-9Dänisch, Niederländisch, Englisch, Finnisch, Französisch, Deutsch, Italienisch, Norwegisch, Portugiesisch, Spanisch, Schwedisch, Türkisch
ISO8859-11Englisch, Thai
Shift JISEnglisch, Japanischja
GB2312-80Englisch, Chinesischja
Big 5Englisch, Taiwanesischja
KSC5601Englisch, Koreanischja
TIS620Englisch, Thaija

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

NameUnterstütze Sprachen
Asian Unification – Variante 1Englisch, Japanisch und Chinesisch
Asian Unification – Variante 2Englisch, Japanisch und Koreanisch
Asian Unification – Variante 3Englisch, Japanisch und Thai
NagamesischJapanisch, Thai und Englisch
Silk RoadJapanisch, Englisch und Griechisch
Trans-SibirischJapanisch, Englisch und Russisch

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

SAP Code PageNameSprachen
11801180ISO1 + Transliteration von ISO2 nach ISO1
18101810Hebärisch und Left To Right Mark (LTRmark)
6240Asian Unification 1Englisch, Japanisch, Chinesisch
6250Asian Unification 2Englisch, Japanisch, Koreanisch
6230Asian Unification 3Englisch, Japanisch, Thai
6600NagamasaJapanisch, Thai, Englisch
6300EurojapanDeutshc, Englisch, Franzäsisch, Italienisch, Dänisch, Niederländisch, Finnisch, Norwegisch, Portugiesisch, Spanisch, Schwedisch, Japanisch
6400Silk RoadJaüanisch, Englisch, Griechisch
6700Trans-SibierischJapanisch, Englisch, Russisch

Liste der Ambiguous Blended Code Pages unter SAP

Code PageNameSprachen
6100SAP UnificationDeutsch, Englishc, Französisch, Italienisch, Dänisch, Niederländisch, Finnisch, Norwegisch, Portugiesisch, Spanisch, Schwedisch, Jaüansich, Tschechisch, Ungarisch, Polnisch, Slowakich, Rumänisch, Slowenisch, Kroatisch, Türkisch, Griechisch
6200Asian UnificationEnglisch, Japanisch, Chinesisch, Koreanisch, Taiwanesisch
6500DiocletanDeutsch, Englisch, Französisch, Italienisch, Dänisch, Niederländisch, Finnisch, Norwegisch, Portugiesisch, Spanisch, Schwedisch, Griechisch

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.

SAP Unicode RFC Verbindung zu Non Unicode

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. Ambiguous Blended Code Page oder MDMP Systeme können die DMO nicht verwenden.: 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.Database Migration Option (DMO) mit Unicode Conversion

 

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.

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.

Das könnte Dich auch interessieren …

2 Antworten

  1. Stefan R. sagt:

    Hallo Andreas,

    hast du wirklich noch Kunden, die noch nicht auf Unicode sind? Wahnsinn, dass es das noch gibt. Die müssen doch ihr System seit der Installation nicht mehr angerührt haben. Ich wusste gar nicht, dass Basis so dein Forte ist. Ich habe dich damals über deine Posts zu Simple Finance gefunden und hätte dich für einen FI-ler gehalten.

    Gruß Stefan

    • DaFRK sagt:

      Lieber Stefan,

      vielen Dank mal wieder für deinen Kommentar. Als Basis Berater würde ich mich persönlich nicht bezeichnen. Ich mache seit 2006 IT generell, seit 2014 SAP Basis und SAP Security, seit 2017 Business Warehouse und IT Management und seit 2018 Compliance. Ich wachse einfach mit meinen Aufgaben. Ich behaupte nicht, alles zu können. Viel eher verstehe ich die Grundprinzipien, wie IT, SAP, Prozesse und Menschen funktionieren (weil das meine Leidenschaft ist), und versuche das auf meine tägliche Arbeit anzuwenden. Ich persönlich denke, dass viele SAP-Berater dieses Talent haben, aber häufig nicht die Möglichkeit dazu bekommen, sich voll zu entfalten. Ich persönlich lasse mich eigentlich nicht gerne in eine Schublade stecken a la: Der Loibl der macht FI, oder: Der Andy macht Basis. Ich sehe mich eher als Prozessberater und lebe das auch.

      Ich schreibe gerade auch deshalb so viel über Basis Themen, weil ich in diese Themen nicht so sehr investiert bin und das Wissen, welches ich in diesen Bereichen erworben habe, gerne offen mit der Community teile. Weil halt eben nicht mein Leben davon abhängt, wenn ein anderer Berater das liest und bei seinem Kunden anwendet. Weil ich mit meinem Content halt echten Content liefern und kein 700 Wörter Bullshit Bingo abliefern möchte, wird’s auch meistens recht technisch. Ich persönlich bin nämlich immer sehr frustriert, wenn ich mich über ein Thema informieren will und dann irgendeinen Buchstabensalat ohne technische Inhalte präsentiert bekomme. Ich hoffe, dass euch die Inhalte gefallen, und die Tatsache, dass du ein zweites mal kommentierst, gibt mir ein gutes Gefühl.

      Wenn du meinen Blog oder auch mein Profil liest, wirst du merken, dass ich eher ein breit aufgestellter Berater bin und vor allem versuche, mit der Zeit zu gehen und mich von der Digitalisierung nicht abhängen zu lassen. In meinen Augen entscheidet sich in den nächsten Jahren bis 2025, wer in der SAP Beratung überlebt und wer auf der Strecke bleibt. Es ist nämlich in diesem Bereich ziemlich einfach, in seiner Komfortzone zu bleiben und „den Schuss nicht zu hören“ – wenn du mich fragst. Wir werden sehen, was die Zeit uns bringt.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.