REALTECH AG
Fachbeiträge<br />

ERP Sprachprobleme lösen

Erschienen in der Sapport 05/2007


Autor: Jochen Raab, REALTECH AG

Geschäftsprozesse verlaufen heute über Ländergrenzen hinweg. Produktionsstandorte, Vertriebsbüros, Verwaltung, Kunden und Lieferanten eines Unternehmens sind über den gesamten Globus verteilt. Die internationale Verflechtung der Firmen und die zunehmende Intensivierung globaler Wirtschaftsbeziehungen zwingt diese zum technischen Umdenken.
Die Unternehmen müssen verschiedene Schriften, unterschiedliche Zeitzonen, Kalender oder Währungen berücksichtigen, die das Internet als Kommunikationsplattform mit sich bringt. Aber auch die verschiedenen Sprachen stellen eine Herausforderung für eine global eingesetzte Softwarelösung, wie SAP NetWeaver, dar.

Unicode – Anforderung der Zukunft?

Manch ein IT-Leiter wird denken, dass er mit seinen bestehenden Systemen auch in Zukunft problemlos die Anforderungen an eine moderne IT bewältigen kann. Derzeit besteht anscheinend noch kein Grund für eine Unicode-Umstellung, da das Unternehmen noch nicht global ausgerichtet ist. Bereits die Dateneingabe über das Internet kann zu Problemen im Backend-System führen. Erhält ein Hamburger Unternehmen eine Bestellung aus Westeuropa, so stellt der Web-Browser die Daten ohne Einschränkungen korrekt dar. Die gleiche Bestellung aus Osteuropa wird eine Dateninkonsistenz hervorrufen, da das Backend-System die Bestellinformationen aufgrund einer anderen Codepage nicht korrekt verarbeiten kann.

Vom „Common Character Set“ zum Unicode Standard

Alle Schriftzeichen, wie Buchstaben, Ziffern oder Symbole, die ein Computersystem verarbeitet, sind in einem Binärformat gespeichert. Um diese Bitfolgen einem eindeutigen Zeichen zuordnen zu können, verwendet man Zuordnungstabellen, die so genannten Codepages. Zur Vereinheitlichung dieser, wurde 1963 die erste 7-Bit Version des ASCII Codes definiert. Dieser wird als „Common Character Set“ bezeichnet. Der Code umfasst 128 Zeichen darunter das lateinische Alphabet in Groß- und Kleinbuchstaben, die zehn Ziffern, sowie einige Satz- und Steuerzeichen. Dieser grundlegende Zeichensatz ist in jeder Codepage enthalten und immer einheitlich kodiert. Eine Darstellung von landesspezifischen Sonderzeichen, beispielsweise der deutschen Umlaute, ist mit dem 7-Bit Code allerdings nicht vollständig möglich. Als Erweiterung für die Zeichencodierung hat man deshalb das 8. Bit verwendet und so den Code um weitere 128 Zeichen auf 256 darstellbare Zeichen pro Codepage erweitert.
Die Normenfamilie ISO 8859 der International Organization for Standardization enthält 16 verschiedenen 8-Bit Zeichensätze. Durch eine Zusammenfassung landesspezifischer Sonderzeichen wie im ISO 8859-1, der so genannten Latin-1 Codepage, ist es möglich, mehrere westeuropäische Sprachen mit einer Codepage darzustellen. Ist also ein System mit der ISO Codepage 8859-1 installiert, kann es neben Deutsch und Englisch noch neun weitere westeuropäische Sprachen nutzen. Solche Installationen nennt man Single-Codepage-System. Jede Codepage kann Englisch darstellen, da es im Common Character Set enthalten ist. Asiatische Sprachen hingegen benötigen aufgrund der zahlreichen zu verarbeitenden Zeichen eine Double-Byte-Codepage. Für die Darstellung von asiatischen Zeichen werden zwei Byte benötigt.

Wenn Entwickler neben den westeuropäischen noch osteuropäische Sprachen verwenden mussten, so waren sie bisher gezwungen, ein ERP-System mit mehreren unterschiedlichen Codepages zu betreiben. Anbieter wie SAP verwenden hierfür das Multiple-Display-Multiple-Processing (MDMP), das in sehr vielen global eingesetzten SAP-Systemen zum Einsatz kommt. Bei dieser Methode wird auf dem SAP Applikationsserver - je nach Anmeldesprache des Benutzers - dynamisch zwischen den installierten Codepages umgeschaltet.

Die Herausforderung bestand darin, ein System zu schaffen, in dem man ohne Umwege und Einschränkungen die weltweit genutzten Textzeichen und Sprachen in einer einzigen Codepage nutzen kann. Um den Anforderungen der verschiedenen Zeichen und Sprachen nachkommen zu können, verabschiedete das Unicode-Konsortium 1991 den Unicode-Standard. Diese von Hardware und Software unabhängige Norm unterstützt weltweit alle bedeutenden IT-Unternehmen. Darunter IBM, Microsoft, Oracle, SAP, Sun, HP und Apple.
Unicode ist die Voraussetzung für einheitliche IT-Standards und Programmiersprachen. Mit der Vereinbarung des Unicode-Standards haben die beteiligten Unternehmen einen Weg aus dem proprietären „Codepage-Dschungel“ gefunden. Wie auch schon in der ursprünglichen Methode ordnet der Unicode-Standard den Zeichen aller wichtigen Sprachen eindeutige Bitfolgen zu. Doch das auf Unicode basierende IT-System hat nur noch eine Codepage. Mit Unicode sind Systeme jetzt in der Lage, Daten ohne Informationsverlust oder Konvertierungen untereinander auszutauschen. Anwender sparen dadurch anfällige und teure Konvertierungsprogramme oder zusätzliche Anpassungen.

Die Umstellung

Die Umstellung eines Datenbestandes auf Unicode ist ein schwerer Eingriff in die Datenhaltung. IT-Verantwortliche sollten ihn trotz bekannter Migrationsmethoden nicht unterschätzen. Grundsätzlich wird die Umstellung in drei Bereiche unterteilt:

 

  • die Vorbereitung und Überprüfung des Datenbestandes,
  • die Konvertierung der Datenbank/Export und Import und
  • die Nachbereitung.

 

Im Folgenden wird die Unicode-Umstellung exemplarisch am Beispiel des SAP NetWeaver dargestellt.

Vorbereitung und Überprüfung des Datenbestandes


Zunächst gilt es festzustellen, ob das Release des zu konvertierenden SAP-Systems überhaupt Unicode-fähig ist. Ältere Systeme wie SAP R/3 Release 3.1I – 4.6C sind nicht mit Unicode verwendbar. So muss zuerst ein Upgrade auf mySAP ERP 2005 mit anschließender Unicode-Konvertierung erfolgen. Zudem sollte mit einem Hardwarepartner geklärt werden, ob die aktuell eingesetzten Server die erhöhte Speicher-Belastung mit Unicode verkraften. In einem weiteren Schritt gilt es das Augenmerk auf die von SAP herausgegebenen Konvertierungsleitfäden zu richten. Diese orientieren sich an dem Basis-Release und dem Stand der eingesetzten Basis-Support-Packages. Ältere Stände der Konvertierungsleitfäden bedeuten unter Umständen einen Mehraufwand in der Vor- und Nachbereitung.

Konvertierung der Datenbank / Export und Import


Für das Export- und Importverfahren stützt sich SAP auf das bereits verwendete Verfahren bei Betriebssystem oder Datenbankmigration. Bei dieser vielfach bewährten Vorgehensweise werden die Daten beim Export in Unicode konvertiert und als Dump-Files auf Betriebssystem-Ebene gespeichert. Nachdem die Datenbank vollständig gelöscht ist, werden diese Dateien von den Import-Tools wieder in die neue Datenbank eingespielt. Für die Konvertierungslaufzeiten lässt sich aufgrund von individuellen Einflussfaktoren, wie der Datenbank-Größe oder der Leistungsfähigkeit der Server, keine eindeutige Regel ableiten. Jedoch gibt es mehrere Möglichkeiten der Laufzeitoptimierung außerhalb der SAP-Standardeinstellungen. Diese sollten allerdings nur von erfahrenen Migrateuren angewendet werden.

Oftmals nehmen IT-Verantwortliche fälschlicherweise an, dass sich die Datenbankgröße bei einer Konvertierung eines Non-Unicode Systems in ein Unicode-basierendes Systems verdoppelt oder zumindest stark vergrößert. Das muss aber nicht sein. Während der Umsetzung der Daten in einem SAP NetWeaver-System wird der komplette Datenbestand exportiert und anschließend wieder importiert. Dieser Vorgang reorganisiert alle Tabellen und baut alle Indizes neu auf. Diese Reorganisation führt in vielen Fällen dazu, dass nicht mehr Plattenspeicher benötigt wird. Mit rund 50 Prozent Mehrbedarf muss man allerdings im Hauptspeicherbereich rechnen, da die Daten auf dem SAP-Applikationsserver mit UTF-16 (16 Bit pro Zeichen) dargestellt werden. Wie Messungen von SAP zeigen, muss im Bereich der Central Processing Unit (CPU) mit etwa 30 Prozent zusätzlicher Last gerechnet werden.
Ein nicht zu unterschätzender Kostenanteil bei einer Unicode-Konvertierung ist sicherlich auch der Einsatz der benötigten Fachleute. Empfehlenswert ist eine Zusammensetzung des Projekt-Teams aus den Experten der internen Fachabteilungen und externen Spezialisten, die bereits Erfahrung in diesem Gebiet mitbringen.

Nachbereitung


Bevor das System freigegeben werden kann, müssen noch einige manuelle Nachbearbeitungsschritte durchgeführt werden. Diese beinhalten neben der Reparatur von inkorrekt konvertierten Texten auch die Anpassung der SAP Profilparameter an die neue Umgebung.

Fazit


Die internationale Verflechtung der Unternehmen und die zunehmende Intensivierung globaler Wirtschaftsbeziehungen erfordert von den IT-Abteilungen technisches Umdenken.
Unicode ist nicht nur für weltweit agierende Unternehmen wichtig. Auch viele lokale Firmen sind hiervon betroffen. In erster Linie handelt es sich um Anbieter von Internet-basierten Diensten, wie Online-Shops. Die Umstellung eines Non-Unicode Systems auf ein Unicode-System ist keine einfache Angelegenheit. Sie bedarf einer sorgfältigen und vorausschauenden Planung. Auf Basis von Unicode können Daten ohne Informationsverlust oder Konvertierungen untereinander ausgetauscht werden. So sparen sich Anwender beispielsweise anfällige und teure Konvertierungsprogramme. Unternehmen können durch die Standardisierung erhebliche Kosteneinsparungen erzielen.