Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

16.01.2007

Unicode löst ERP-Sprachprobleme

Jochen Raab 
Wenn global agierende Unternehmen ihre betriebswirtschaftlichen Systeme konsolidieren, müssen sie für kompatible Zeichensätze sorgen. Von Jochen Raab*

Die Globalisierung zwingt Unternehmen, in anderen Dimensionen zu denken, als es vor zehn Jahren noch der Fall war. Geschäftsprozesse verlaufen heute über Ländergrenzen hinweg. Produktionsstandorte, Vertriebsbüros, Verwaltung, Kunden und Lieferanten sind weltweit verteilt. Darüber hinaus bringt das Internet als Kommunikationsplattform eine Vielzahl von Problemen mit sich. So müssen die Anwender verschiedene Schriften, unterschiedliche Zeitzonen, Kalender oder Währungen berücksichtigen. Aber auch die verschiedenen Sprachen stellen eine Herausforderung für eine global eingesetzte Softwarelösung und die betroffenen Entwickler dar.

Mehr zum Thema,www.computerwoche.de/go/

581295: Auswahltipps für SAP-Datenbanken;

580821: Unicode sorgt für Einheitlichkeit;

574944: Unicode beseitigt Sprachbarrieren;

1215250: Internationalisierung - Theorie und Praxis.

Hier lesen Sie ...

- welche Vorteile Unicode im ERP-System bietet;

- wie eine Umstellung des Zeichensatzes angegangen werden sollte;

- welche Unternehmen sich mit einer Unicode-Umstellung befassen sollten.

Unicode für alle?

Manch ein IT-Leiter wird sich denken, dass er mit seinen Systemen auch in Zukunft problemlos alle Anforderungen an eine moderne IT bewältigen kann. Das scheint vor allem dann so, wenn das Unternehmen noch nicht global ausgerichtet ist. Aber auch in Europa gibt es zahlreiche Sprachen, die Schwierigkeiten im ERP-Backend verursachen können: Bereits die Dateneingabe über das Internet kann Ärger machen. Erhält beispielsweise 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 Bit-Folgen eindeutig je einem Zeichen zuordnen zu können, verwendet man Tabellen, die Codepages. Um diese zu vereinheitlichen, wurde 1963 die erste 7-Bit-Version des Ascii-Codes definiert, der "Common Character Set". Dieser 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 codiert. 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 achte Bit verwendet und so den Code um weitere 128 auf 256 darstellbare Zeichen pro Codepage erweitert.

Die Normenfamilie ISO 8859 der International Organization for Standardization enthält 16 verschiedene 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 neun weitere westeuropäische Sprachen nutzen. Solche Installationen nennt man Single-Codepage-Systeme: 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. Um asiatische Zeichen darstellen zu können, sind 2 Bytes notwendig.

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 vielen global eingesetzten SAP-Systemen zum Einsatz kam. Bei dieser Methode wird auf dem SAP-Applikations-Server - je nach Anmeldesprache des Benutzers - dynamisch zwischen den installierten Codepages umgeschaltet.

Die Herausforderung bestand indes darin, ein System zu schaffen, in dem Anwender ohne Umwege und Einschränkungen die weltweit genutzten Textzeichen und Sprachen in einer einzigen Codepage verwenden können. Um den Anforderungen der verschiedenen Zeichen und Sprachen gerecht zu werden, verabschiedete das Unicode-Konsortium 1991 den Unicode-Standard. Diese von Hardware und Software unabhängige Norm unterstützen weltweit alle bedeutenden IT-Unternehmen, darunter IBM, Microsoft, Oracle, SAP, Sun Microsystems, Hewlett-Packard und Apple.

Unicode ist die Voraussetzung für einheitliche IT-Standards und Programmiersprachen. Mit dem Unicode-Standard haben die beteiligten Unternehmen einen Weg aus dem proprietären Codepage-Dschungel gefunden. Gleichzeitig ermöglichten sie durch diese Standardisierung den Anwendern, die Kosten beim Betrieb ihrer ERP-Systeme zu senken. Wie 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 sich dadurch anfällige und teure Konvertierungsprogramme oder zusätzliche Anpassungen.

Die Unicode-Umstellung

Einen Datenbestand auf Unicode umzustellen ist ein schwerer Eingriff in die Datenhaltung. IT-Verantwortliche sollten ein solches Projekt trotz bekannter Migrationsmethoden nicht unterschätzen. Grundsätzlich wird die Umstellung in drei Bereiche unterteilt:

- Datenbestand überprüfen und vorbereiten,

- die Datenbank konvertieren/Export und Import und

- den Datenbestand nachbereiten.

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

Vorbereitung und Überprüfung des Datenbestands

Zunächst muss das Projektteam festlegen, ob das Release des zu konvertierenden SAP-Systems überhaupt Unicode-fähig ist. Ältere Releases wie SAP R/3 Release 3.1I bis 4.6C sind nicht mit Unicode verwendbar. Demnach ist ein Upgrade auf Mysap ERP 2005 notwendig. Erst danach kann eine anschließende Unicode-Konvertierung erfolgen. Außerdem müssen die Verantwortlichen mit Hilfe des Hardwarepartners klären, ob die aktuell eingesetzten Server die erhöhte Speicherbelastung mit Unicode verkraften. Weiteres Augenmerk sollten sie auf die von SAP herausgegebenen Konvertierungsleitfäden richten. Diese richten sich nach 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 wiederverwendet. Für die Laufzeit der Konvertierung gibt es keine eindeutige Regel. Individuelle Einflussfaktoren wie die Datenbankgröße oder die Leistungsfähigkeit lassen an dieser Stelle keine allgemein gültigen Aussagen zu. Mehrere Möglichkeiten der Laufzeitoptimierung bestehen außerhalb der SAP-Standardeinstellungen. Diesen Weg sollten allerdings nur migrationserfahrene Anwender einschlagen.

Oftmals nehmen IT-Verantwortliche fälschlicherweise an, dass sich die Datenbankgröße bei einer Konvertierung eines Non-Unicode- in ein Unicode-basierendes System verdoppelt oder zumindest stark ansteigt. Das muss aber nicht sein. Beispielsweise wird während der Umsetzung der Daten in einem SAP-Netweaver-System der komplette Datenbestand exportiert und anschließend wieder importiert. Dieser Vorgang reorganisiert alle Tabellen und baut sämtliche Indizes neu auf. In vielen Fällen führt die Reorganisation zu einem Ausgleich des Mehrbedarfs an Plattenspeicher durch die Unicode-Codepage.

Mit rund 50 Prozent Mehrbedarf muss man allerdings im Hauptspeicherbereich rechnen, da die Daten auf dem SAP-Applikations-Server mit UTF-16 (16 Bit pro Zeichen) dargestellt werden. Wie Messungen von SAP zeigen, ist im Bereich der Central Processing Unit (CPU) mit etwa 30 Prozent Mehrbedarf zu rechnen. Nicht zu unterschätzen bei einer Unicode-Konvertierung sind die Kosten für die benötigten Fachleute. Empfehlenswert ist eine Zusammensetzung des Projektteams aus Experten der internen Fachabteilungen und externen Spezialisten, die bereits Erfahrung in diesem Gebiet mitbringen.

Nachbereitung

Bevor das System freigegeben werden kann, muss das Team in aller Regel noch manuell nacharbeiten. Das beinhaltet beispielsweise neben der Reparatur von inkorrekt konvertierten Texten auch die Anpassung der SAP-Profilparameter an die neue Umgebung.

Fazit

Die zunehmende Globalisierung der Unternehmenswelt erfordert ein Umdenken der IT-Abteilungen. Unicode ist dabei nicht nur für weltweit agierende Unternehmen wichtig. Auch viele lokale Firmen sind durch die weitreichende Vernetzung mit Geschäftspartnern betroffen. In erster Linie handelt es sich dabei um Anbieter von Internet-basierenden Diensten wie Online-Shops. Die Umstellung eines Non-Unicode-Systems auf Unicode ist keine einfache Angelegenheit, sie bedarf einer sorgfältigen Planung. (ba)

*Jochen Raab ist Senior Consultant der Realtech AG