Computer bearbeiten und speichern jedes Zeichen, beispielsweise ein “B”, als eine Bytefolge. Die Zeichen und Bytefolgen werden in einer Codepage definiert. Die Vielfalt an Sprachen und Schriftsystemen erfordert viele Codepages, zudem wird je nach Betriebssystem oder Druckerhersteller das gleiche Zeichen anders abgebildet. Aus diesem Grund sind im SAP-System derzeit 390 Codepages definiert, um 41 Sprachen zu unterstützen. Diese zahlreichen, großteils redundanten Codepages erschweren den Datenaustausch und behindern damit die Integration.
Technologien, die auf Unicode aufbauen, haben dieses Problem nicht. Unicode bildet die Zeichen aller Schriften der Welt standardisiert ab und erlaubt daher eine reibungslose Kommunikation zwischen unterschiedlichen Sprachen und Systemen. Derzeit sind rund 98.000 Zeichen in Unicode definiert und es ist Platz für mehr als eine Million Zeichen vorgesehen. Unicode zu verwenden, bringt zahlreiche Vorteile:

• Viele unterschiedliche Sprachen lassen sich einfacher unterstützen
• Ohne Unicode droht immer die Gefahr eines Datenverlusts
• Eine enge Integration mit anderen Unicode-basierten Technologien wie XML, VB, JAVA und .NET ist möglich.

Da ein Unicode-System nur eine Codepage verwendet, gelten die Einschränkungen von Systemen mit mehr als einer Codepage (Multi-Display, Multi-Processing, MDMP) natürlich nicht: Jeder Benutzer kann sich zum Beispiel in Englisch anmelden und beliebige Unicode-Zeichen eingeben.

Eindeutige Identifikation, mehrere Kodierungen

Jedes Zeichen im Unicode-Standard besitzt eine eindeutige Identifikationsnummer (Unicode Scalar Value). Es gibt mehrere Möglichkeiten, eine Zahl darzustellen – “zehn” wird normalerweise “10” geschrieben, ein Computer stellt sie aber binär “1010” dar. Analog dazu gibt es drei Unicode Transformation Formats (UTF), die einen Unicode Scalar Value in 8-, 16- oder 32-bit-Einheiten kodieren.
Die Möglichkeit, jedes Zeichen einmal in 8-bit und einmal in 16-bit zu kodieren, bringt enorme Vorteile. Eine 16-bit-Kodierung eignet sich besser für die systeminterne Zeichenverarbeitung, während sich eine 8-bit-Kodierung für den Datenaustausch anbietet, da sie die Datenmenge kleiner hält. Unabhängig von der Art der Kodierung sind alle Unicode-Zeichen in sämtlichen Unicode Transformation Formats definiert. Die Konvertierung zwischen Unicode Transformation Formats erfolgt mathematisch – ähnlich wie die Umrechnung von Basis 10 in Basis 2. Damit ist die Konvertierung effizient und eindeutig.

SAP Web Application Server unterstützt Unicode

Die Unicode-Umstellung von mySAP.com begann mit dem SAP Web Application Server (SAP Web AS) 6.10. Inzwischen unterstützen mehrere mySAP-Lösungen Unicode. Unter anderem SAP R/3 Enterprise, mySAP Business Intelligence, mySAP Supply Chain Management und einige Szenarien von mySAP Customer Relationship Management. Regeln über Freigabe-Genehmigungen und aktuelle Informationen sind im SAP-Hinweis 79991 nachzulesen. Weitere Anwendungen werden Unicode in zukünftigen Releases unterstützen.

Ein Unicode-System verwendet Unicode auf jeder Systemebene: Datenbank, Application Server und GUI. Inzwischen bieten alle führenden Datenbank-Hersteller Unicode-Datenbanken an. Da im SAP GUI 6.20 Unicode-Unterstützung bereits integriert ist, benötigen SAP-Anwender lediglich einen SAP GUI, um mit Unicode- und Nicht-Unicode-Systemen gleichzeitig zu arbeiten. In einem Unicode-System sind alle Zeichen stets richtig dargestellt (siehe Screenshot).
In einem Unicode-System definiert die ICU-Bibliothek (International Components for Unicode) unter anderem die Zeicheneigenschaften und die sprachabhängige Sortier-Reihenfolge. ICU ersetzt betriebssystem-abhängige Locales und bietet diese Funktionalität unabhängig von der Computersprache (C, ABAP und Java).

Existierende Systeme umstellen

Jede Unicode-fähige mySAP-Komponente lässt sich als Unicode- oder Nicht-Unicode System installieren. Ein Unicode-System neu zu installieren erfordert keine besonderen Maßnahmen. Daher ist für Neu-Installationen ein Unicode-System zu empfehlen.
Bevor ein existierendes System umgestellt wird, sind allerdings verschiedene Vorbereitungen zu treffen. Die Umstellung eines nicht-Unicode Systems ist ab SAP Web AS Release 6.20 möglich. Für ältere Releases ist daher ein Upgrade erforderlich, etwa von SAP R/3 4.6C nach SAP R/3 Enterprise. Anschließend gilt es,

• die Datenbank mit SAPINST umzustellen
• die kundeneigenen ABAP-Programme und
• die C/C++-Programme für RFC (Remote Function Call) zu prüfen.

SAPINST exportiert die Datenbank, baut eine neue Unicode-Datenbank auf, und importiert die Daten in die neue Unicode-Datenbank. Die Konvertierung nach Unicode erfolgt während des Exports. Für große Datenbanken arbeitet SAP an der Möglichkeit einer inkrementellen Konvertierung, um die Downtime beim Export gering zu halten.
Werden Systeme umgestellt, die mehr als eine Codepage verwenden (MDMP-Systeme) sind darüber hinaus weitere Schritte notwendig. Um die richtige Datenkonvertierung sicher zu stellen, werden bei einer MDMP-Umstellung alle Sprachenschlüssel ausgewertet. Die Konvertierung muss aber auch dann richtig sein, wenn Tabellen ohne Spracheninformation doch sprachabhängige Daten besitzen sollten. Heuristiken, ein Systemwortschatz sowie das Heranziehen von Geschäftsdaten, etwa Buchungskreise oder Kundennummer, gewährleisten hier eine korrekte Konvertierung. Diese Vorbereitungen lassen sich bereits in einem SAP-R/3-System 4.6C treffen.
In C-Programmen verwenden Unicode- und nicht Unicode-Systeme unterschiedliche Datentypen, es kann aber der gleiche Programm-Code verwendet werden. Um RFC-Programme umzustellen, steht SAP-Kunden das Werkzeug “ccQ” zur Verfügung. Weitere Information über ccQ sind dem SAP RFC Software Development Kit zu entnehmen. Mit der Unicode-Umstellung von ABAP-Programmen, beschäftigt sich ein weiterer weiterer SAP-INFO-Artikel.

Systemübergreifende Integration ohne Sprachbarrieren

Ein Unicode-System kann bedenkenlos in eine Systemlandschaft integriert werden. Und mehr noch: Da Unicode alle Zeichen beinhaltet, die in alten Codepages verwendet wurden, eignet sich ein Unicode-System besonders, um Daten aus alten SAP-Systemen oder Nicht-SAP-Anwendungen zu sammeln. Für eine RFC-Kommunikation konvertiert das Unicode-System nach der Codepage (oder den Codepages) des Empfängers. Daher ist es lediglich im Unicode-System notwendig, die RFC-Verbindungen besonders zu pflegen.
Grundsätzlich ist es jederzeit machbar, zwischen Codepages zu konvertieren und auf diese Weise Daten zwischen Systemen oder Programmen auszutauschen. Damit die Konvertierung funktioniert, müssen allerdings Sender und Empfänger Codepages verwenden, die die gleiche Zeichenmenge definieren. Zudem ist es notwendig, dass beide Seiten die Codepage(s) ihres Partners kennen, da andernfalls Daten verloren gehen. Daher wird zunehmend Unicode genutzt, insbesondere dann, wenn Daten innerhalb und außerhalb von SAP-Systemen ausgetauscht werden. Aus diesem Grund baut auch die SAP Exchange Infrastructure (SAP XI) auf Unicode auf, um eine prozessgesteuerte Kollaboration zu ermöglichen. Da ABAP und Java Unicode verwenden, ist auch bei einem Datenaustausch, der tiefer im System erfolgt, eine enge Integration möglich. Ohne Unicode dagegen ist jede Art von Integration durch Codepage-Probleme gefährdet.
Weiterführende technische Informationen, Leitfäden und Übersichten zu den oben erwähnten Themen sind im SAPNet unter dem Alias Unicode@sap in der Media Library zu finden. Interessenten für ein Unicode-System wenden sich bitte an globalization@sap.com.