832.book Seite 3 Montag, 9. Oktober 2006 12:57 12

Bonn � Boston

Nils Bürckel, Alexander Davidenkoff, Detlef Werner

Unicode mit SAP®

832.book Seite 3 Montag, 9. Oktober 2006 12:57 12

Auf einen Blick

Vorwort ................................................................... 11

1 Einführung .............................................................. 13

2 Sprachunterstützung in SAP-Systemen ................. 27

3 Realisierung von Unicode in SAP-Applikationen ... 59

4 Leitfaden für Unicode-Projekte .............................. 243

5 Sprachen und Übersetzung ..................................... 265

6 Zusammenfassung .................................................. 289

A Codepage-Tabellen ................................................. 293

B Sprachen in einem SAP-Unicode-System ............... 299

C Literaturverweise und sonstige Hilfestellungen ..... 313

D Glossar .................................................................... 319

E Die Autoren ............................................................. 325

Index ....................................................................... 327


7

Inhalt

Vorwort ...................................................................................... 11

1 Einführung ............................................................... 13

1.1 Globalisierung und Lokalisierung ............................. 131.2 Sprachunterstützung in IT-Systemen ........................ 161.3 Unicode ................................................................... 19

1.3.1 Zeichenkodierung ....................................... 201.3.2 Java und Unicode ........................................ 221.3.3 Entwicklung von Unicode ............................ 221.3.4 Moderne Geschäftsprozesse und die

Erschließung neuer Märkte .......................... 241.4 Zusammenfassung ................................................... 26

2 Sprachunterstützung in SAP-Systemen .................. 27

2.1 Von Single-Codepage-Systemen zu Unicode ............ 272.1.1 Zeichen, Zeichensätze und Codepages ........ 282.1.2 Historische Entwicklung der

Sprachverarbeitung bei SAP ........................ 292.1.3 Single-Codepage-Systeme ........................... 32

2.2 Kombination von Sprachen in einem System ............ 372.2.1 »Fool the System« ....................................... 392.2.2 MNLS-System ............................................. 392.2.3 Blended-Codepage-System ......................... 402.2.4 MDSP-System ............................................. 422.2.5 MDMP-System ........................................... 42

2.3 Unicode im SAP-System .......................................... 492.3.1 Multilingualer Datenaustausch .................... 502.3.2 Unicode-Grundlagen ................................... 512.3.3 Unicode-Formate in SAP-Systemen ............. 53

2.4 Transition zu SAP NetWeaver und Enterprise SOA mit Unicode ..................................................... 54

2.5 Zusammenfassung ................................................... 57

3 Realisierung von Unicode in SAP-Applikationen .... 59

3.1 Unicode-Architektur ................................................ 593.2 Unicode-Konvertierung ........................................... 63


Inhalt

8

3.2.1 Allgemein notwendige Konvertierungs-schritte in einem System .............................. 63

3.2.2 MDMP- bzw. Blended-Codepage-spezifische Schritte ...................................... 70

3.2.3 Export und Import ....................................... 993.2.4 SAP GUI für Windows ................................. 1043.2.5 Drucken im Unicode-System ....................... 1103.2.6 Transport zwischen Non-Unicode- und

Unicode-Systemen ...................................... 1123.2.7 Konvertierung von SAP NetWeaver BI und

mySAP CRM ................................................ 1133.2.8 Zusammenfassung ....................................... 114

3.3 Upgrade und Unicode-Konvertierung ....................... 1143.3.1 Sequenzielles (getrenntes) Upgrade und

Unicode-Konvertierung ............................... 1183.3.2 Kombiniertes Upgrade und Unicode-

Konvertierung ............................................. 1193.3.3 Twin-Upgrade und Unicode-

Konvertierung ............................................. 1303.3.4 Vergleich der Kombinationsverfahren .......... 133

3.4 ABAP und Unicode .................................................. 1353.4.1 Überblick .................................................... 1363.4.2 Unicoderelevante Änderungen und

Neuerungen in ABAP seit SAP Web AS 6.10/6.20 ............................................... 138

3.4.3 Werkzeuge zur Unicode-Anpassung ............ 1543.4.4 Zusammenfassung ....................................... 161

3.5 Kommunikation und Schnittstellen .......................... 1613.5.1 Homogene und inhomogene

Kommunikation .......................................... 1633.5.2 Kommunikation mit RFC ............................. 1673.5.3 Kommunikation mit File-Transfer ................ 1813.5.4 Kommunikation zwischen SAP-Unicode-

und SAP-Non-Unicode-MDMP-Systemen .. 1863.6 Expansion in neue Länder mit Unicode .................... 227

3.6.1 Technische Konfiguration einer neuen Sprache in SAP-Unicode .............................. 229

3.6.2 Fallstudie: Einführung von Vietnamesisch in einem SAP-Unicode-System .................... 232

3.7 Zusammenfassung .................................................... 239


Inhalt

9

4 Leitfaden für Unicode-Projekte .............................. 243

4.1 Neuinstallation ........................................................ 2434.2 Unicode-Konvertierung ........................................... 244

4.2.1 Typische Schritte eines Konvertierungs-projektes für eine Drei-System-Landschaft .. 244

4.2.2 Rahmenbedingungen eines Konvertierungsprojektes ............................. 251

4.2.3 Vergleich zu Upgrade-Projekten und OS/DB-Migration ........................................ 255

4.2.4 Konvertierung komplexer Landschaften ....... 2584.3 Release-Wechsel und Unicode-Konvertierung ......... 2594.4 Systemkonsolidierung .............................................. 2634.5 Zusammenfassung ................................................... 264

5 Sprachen und Übersetzung ..................................... 265

5.1 Sprachen- und Übersetzungs-Management .............. 2665.1.1 Übersetzungsobjekte ................................... 2675.1.2 Sprachinstallation ........................................ 268

5.2 Kundenspezifische Übersetzungen ........................... 2705.2.1 Übersetzungsstrategien ............................... 2705.2.2 SAP-Übersetzungswerkzeuge ...................... 2725.2.3 SAP-Übersetzungs-Workbench .................... 2735.2.4 Sprachtransport ........................................... 2755.2.5 Sprachabhängiges Customizing .................... 2795.2.6 Adressversionen .......................................... 284

5.3 Zusammenfassung ................................................... 287

6 Zusammenfassung .................................................. 289

Anhang........................................................................... 291

A Codepage-Tabellen ............................................................. 293B Sprachen in einem SAP-Unicode-System ............................. 299C Literaturverweise und sonstige Hilfestellungen .................... 313

C.1 Literatur .................................................................. 313C.2 Links ........................................................................ 314C.3 SAP-Hinweise .......................................................... 315C.4 Notwendige Dokumente zur Unicode-

Konvertierung .......................................................... 317


Inhalt

10

C.5 Typischer Ablauf des Tests einer Unicode-Konvertierung .......................................................... 317

D Glossar ................................................................................ 319E Die Autoren ........................................................................ 325

Index .......................................................................................... 327


243

Alle SAP-Applikationen sind unicodebasiert verfügbar. In diesem Kapitel lernen Sie, wie Sie eine Neuinstallation oder die Konvertierung eines bestehenden Systems optimal planen und durchführen können.

4 Leitfaden für Unicode-Projekte

Zum heutigen Zeitpunkt sind bereits alle SAP-Applikationen unicode-basiert verfügbar, wobei neue Software-Produkte der SAP (zum Bei-spiel die SAP NetWeaver Exchange Infrastructure oder das SAP Net-Weaver Portal) nur noch als Unicode-Version ausgeliefert werden.Die Unterstützung für veraltete Lösungen zur Kombination von Spra-chen bzw. Codepages – wie MDMP in SAP R/3 – wird schrittweisebeendet, so unterstützt mySAP ERP 2005 MDMP bereits nicht mehr.Ab 2007 werden dann alle Neuinstallationen von auf SAP NetWea-ver basierenden Applikationen nur noch unter Unicode möglichsein.

4.1 Neuinstallation

Neuinstallation unterscheidet sich nicht

Die Neuinstallation eines unicodebasierten Systems unterscheidetsich praktisch nicht von der einer Non-Unicode-Installation. Es gibtaber ein paar Punkte, die man im Implementierungsprojekt berück-sichtigen muss:

� Wie in Kapitel 3 erwähnt, hat ein Unicode-System etwas höhereHardware-Anforderungen; diese müssen natürlich berücksichtigtwerden.

� Bestehen Schnittstellen zu Non-Unicode-Systemen, muss die Kon-figuration sorgfältig erfolgen, um z.B. das Risiko von Datenverlus-ten durch falsche Konvertierung auszuschließen.

� Gleiches gilt für den Up- oder Download von Dateien, die überdas Netzwerk (z.B. mittels FTP) in die Systeme gelangen.


244

Leitfaden für Unicode-Projekte4

� Wenn Drittanbieter-Software angebunden werden soll, ist sorgfäl-tig zu prüfen, ob Letztere mit der SAP-Unicode-Installation rei-bungslos funktioniert, oft reicht eine Anfrage beim jeweiligenSAP-Software-Partner.

� Bei der Erstellung von Eigenentwicklungen ist unicodekonformvorzugehen, wie z.B. im SAP Unicode Enabling Cookbook (sieheAnhang C) und in Abschnitt 3.4 beschrieben.

Workshops vonSAP Globalization

Services

4.2 Unicode-Konvertierung

4.2.1 Typische Schritte eines Konvertierungsprojektes für eine Drei-System-Landschaft

Einen groben Überblick bzgl. der Konvertierung eines SAP-Systemserhalten Sie durch Abbildung 4.1, die die typischen Phasen einerKonvertierung zeigt. Das Schema für eine Konvertierung ist immerdas gleiche: Die Vorbereitung nimmt einen sehr wichtigen Platz ein,es folgt die eigentliche Konvertierung und dann die Phase der Nach-bereitung.

Abbildung 4.1 Übersicht der notwendigen Schritte bei der Konvertierung eines SAP-Systems

Tipp

SAP Globalization Services bietet verschiedene Services und Workshopsan, die vor einem Projekt oder Projekt begleitend je nach den Kundenan-forderungen auf einzelne Unicode-Aspekte im Detail eingehen. Der SAPUnicode Workshop ist dabei der ideale Einstieg für alle Unicode-Projekte.Die Liste aller Services findet man im SAP Service Marketplace (http://service.sap.com/globalization) im Bereich Service Offerings.

Vorbereitung KonvertierungNachbereitung

- Konvertierungsprojekt

- Voraussetzungen

- MDMP-Vorbereitung(SPUMG)

- Anpassung der kundeneigenen Objekte (UCCHECK)

- Export-/Importprozess

- Ausfallzeit (Downtime)

- Performance-Optimierung im Falle großer Datenbanken

- Unicode-System wird gestartet

- Verifikation der Daten

- Integrationstests mit Schwerpunkt aufSprachenbehandlung


245

Unicode-Konvertierung 4.2

Im Folgenden soll genauer skizziert werden, wie ein Unicode-Konver-tierungsprojekt für eine Drei-System-Landschaft aussehen kann. AmAnfang steht dabei die Evaluierungsphase, in der herausgearbeitetwird, welche Konsequenzen Unicode für die bestehende Systemland-schaft hat und welche Unicode-Strategie verfolgt werden soll. Hierauffolgt die konkrete Vorbereitungsphase für eine bestimmte Systemland-schaft. Daran schließt sich die Sandbox-Konvertierung als erste Test-umgebung an. Die Sandbox-Konvertierung muss gegebenenfalls mehr-mals wiederholt werden. Parallel dazu können das Entwicklungssystem(DEV) bzw. das Konsolidierungssystem (QAS) bereits konvertiert wer-den. Nachdem alle Tests im QAS und in dem Sandbox-System abge-schlossen sind, erfolgt die Konvertierung des Produktiv-Systems (PRD).

Die hier vorgestellten Schritte müssen natürlich auf die jeweiligeKundensituation angepasst werden. Die Liste erhebt außerdem kei-nen Anspruch auf Vollständigkeit.

Projekt-Evaluierungsphase

Im Vorfeld eines Unicode-Konvertierungsprojektes ist zu klären, wasUnicode für die spezifische Situation des Kunden bedeutet. Dabeisteht in der Regel die Frage des Aufwands bzw. der Kosten im Vor-dergrund. Hierbei sollte aber auch berücksichtigt werden, welcheAufwände verursacht werden und welche Konsequenzen es hat,wenn Unicode nicht eingeführt wird. Häufig ist ein »Business Case«notwendig, um die umfangreichen Investitionen in die neue Technikzu rechtfertigen.

Am Ende dieser Phase sollte die generelle Unicode-Strategie desUnternehmens im SAP-Umfeld klar sein. Allerdings kann es für dieseStrategie durch Änderungen der Rahmenbedingungen im Laufe derZeit Anpassungsbedarf geben, sodass die Gültigkeit in regelmäßigenAbständen zu überprüfen ist.

Die folgenden Punkte beschreiben mögliche Faktoren, die in diesemSchritt zu berücksichtigen sind.

� Vorgang einer Unicode-Konvertierung und Konsequenzen

Was muss bei einer Unicode-Konver-tierung gemacht werden ?

In dieser Phase ist es wichtig, das Prinzip der Unicode-Konvertie-rung zu verstehen. Welche Schritte und welcher Aufwand sindnotwendig, und wo müssen von Kunden Anpassungen gemachtwerden?


246


Informations-beschaffung

� Beschaffung von relevanten kundenspezifischen InformationenUm eine vernünftige Unicode-Strategie erarbeiten zu können,müssen die von SAP verfügbaren Informationen zu Unicode mitden kundeneigenen Daten ergänzt werden. Die folgende Liste ent-hält die wichtigsten Punkte:

� Übersicht der Systemlandschaft (Systeme, Releases, Support-Packages, Frontend-Software etc.)

� Datenbankgrößen (in GB), die 50 größten Tabellen und Hard-ware-Ausstattung aller relevanten Systeme

� Anforderungen bzgl. tolerierbarer Ausfallzeit der einzelnenSysteme

� Codepage-Setup aller Systeme (Unicode, MDMP, Single-Code-page, Blended-Codepage)

� Beschreibung der Interfaces zwischen den Systemen und zuNicht-SAP-Systemen (»grober Interface-Katalog«)

� vorhandene Add-on-Lösungen (SAP und Non-SAP)

� Anzahl und Art der existierenden Eigenentwicklungen

� vorhandene Roll-out-Pläne in weitere Länder für die verschie-denen Systeme

� geplante Systemzusammenführungen

� mögliche Konvertierungsstrategien

Aus diesen Punkten ergibt sich in der Regel die Konvertierungsrei-henfolge für die vorhandenen Systeme. Für die Systeme, diezuerst konvertiert werden sollen, bietet es sich an, an dieser Stelledie Vorgehensweise bzgl. Konvertierungsstrategien (also z.B. Auf-setzen eines Sandbox-Systems), aber auch über Optimierungsme-thoden bzgl. Ausfallzeit (siehe Kapitel 3) zu besprechen.

Konvertierungs-strategien

� Evaluierung der Konsequenzen, falls die Unicode-Konvertierungverschoben wirdKunden sollten sich genau überlegen, was eine Aufschiebung vonUnicode auch aus kurz- und langfristiger Perspektive bedeutet.Hier ist insbesondere der in SAP-Hinweis 79991 beschriebeneSAP-Support von Non-Unicode zu berücksichtigen (siehe Tabelle2.7 in Kapitel 2).


247


� Erfahrungen anderer KundenEin Erfahrungsaustausch mit anderen Kunden bietet zu Projektbe-ginn und auch im Verlauf des Projektes eine gute Möglichkeit, einbesseres Verständnis für mögliche Probleme und Workarounds zubekommen.

� Erste »grobe« AufwandsabschätzungEine erste ungefähre Aufwandsabschätzung sollte die PunkteHardware-Bedarf, Ressourcenbedarf und Projektdauer berücksich-tigen.

� Business Case und erste Projektplanerstellung Aus der obigen Analyse lässt sich ein vorläufiger Projektplanerstellen. Dieser enthält in der Regel noch keine genauen Konver-tierungsdetails.

Projekt-Vorbereitungsphase

In der Vorbereitungsphase des Projektes wird mit den systemspezifi-schen Vorbereitungen für die anstehende Unicode-Konvertierungbegonnen. Voraussetzungen und Einschränkungen sind zu prüfenund gegebenenfalls müssen Patches eingespielt werden. Die notwen-dige Hardware muss beschafft werden. Außerdem sollten alle ver-fügbaren Dokumente zur Unicode-Konvertierung studiert werden.Es bietet sich an, für die anstehende Sandbox-Konvertierung einendetaillierten Projektplan zu erstellen. Folgende Punkte sind zuberücksichtigen:

� Detaillierte Voraussetzungen und Restriktionen

Schritte zur Vorbereitung

Falls Produkte von anderen Herstellern im SAP-Umfeld verwendetwerden, ist es anzuraten, sich die Unicode-Fähigkeit dieser Lösun-gen von den Herstellern bescheinigen zu lassen. Generell kannman nicht davon ausgehen, dass eine SAP-Zertifizierung auch dieUnicode-Fähigkeit bedeutet.

Bei relativ »alten« Patch-Ständen der SAP-Lösungen besteht einehohe Wahrscheinlichkeit, dass ein Update notwendig ist. Bei auf-wändigen Änderungen (z.B. SAP GUI für Windows) sollten aberzunächst die Tests mit aktuellem Patch-Level durchgeführt wer-den, bevor ein weltweiter Roll-out angestoßen wird.


248


� Interface-Katalog mit SprachabhängigkeitenEine Aufstellung aller Interfaces und deren Sprachabhängigkeit(»Werden Texte mit Sonderzeichen übertragen?« etc.) hilft zurIdentifikation kritischer Bereiche.

� Hardware-BeschaffungBei größeren Systemen ist eine Sandbox-Konvertierung unbedingtanzuraten. Die hierfür benötigte temporäre Hardware muss zurVerfügung gestellt werden. Falls bei der Produktivkonvertierungdie Hardware erneuert werden soll, muss dies frühzeitig geplantwerden.

� Möglichkeiten zur Performance-OptimierungZur Vorbereitung einer Sandbox-Konvertierung sollte bereitsuntersucht werden, welche Mittel zur Laufzeitoptimierung zurVerfügung stehen und welche für die erste Konvertierung Sinnmachen. Unter Umständen kann es sein, dass bestimmte Metho-den noch nicht frei verfügbar sind. Für diesen Fall können weitereSchritte notwendig sein.

� Festlegen der Strategie zur Behandlung von ABAP-Objekten(UCCHECK) In diesem Beispiel wird angenommen, dass die ABAP-Objektebereits im Vorfeld angepasst werden (siehe unten).

Archivierungvor der Unicode-

Konvertierung

� Ausschöpfung der Archivierungsmöglichkeiten zur Verringerungder DatenbankgrößeDurch eine Verringerung der Datenbankgröße ist es möglich,mehrere Bereiche bei der Konvertierung zu verbessern: Dies sindzum einen die Export-/Import-Zeiten bei der Produktivkonvertie-rung, aber auch die Laufzeiten von Transaktion SPUMG werdenkürzer, wenn weniger Daten zu scannen sind.

� Notwendige Dokumentation und SAP-HinweiseAlle notwendigen Leitfäden und zugehörigen SAP-Hinweise soll-ten heruntergeladen werden. Im Laufe des Projektes ist ein regel-mäßiger Check zu empfehlen, ob es Anpassungen in den SAP-Hin-weisen oder beim Konvertierungsleitfaden gibt.

� Anpassung der ABAP-Objekte (Unicode-Enabling)Die Behandlung der ABAP-Objekte ist vollständig erst ab demBasis-Release 6.10 mithilfe von Transaktion UCCHECK möglich.Falls das Release 6.10 oder höher ist, lassen sich die Objektebereits im Vorfeld anpassen. Die Objekte sind dann idealerweise


249


sowohl unter Non-Unicode als auch unter Unicode lauffähig. Dasich somit eine gewisse Unabhängigkeit von der Unicode-Konver-tierung ergibt, wird die UCCHECK-Behandlung als eigenständigerPunkt aufgeführt. Für Neuentwicklungen (Anlegen neuer ABAP-Objekte) ab SAP Web AS 6.10 wird das Unicode-Flag standardmä-ßig gesetzt, sodass in diesem Fall die Unicode-Fähigkeit weitge-hend gesichert ist. Existierende Objekte ohne Unicode-Flag, dieim Rahmen der Pflege angepasst werden, sollten hierbei auchgleich unicodefähig gemacht werden, da diese Objekte dann nureinmal getestet werden müssen.

Aufbau und Konvertierung des Sandbox-Systems

»Proof of Concept«Nachdem die Voraussetzungen für die Sandbox-Konvertierunggeschaffen wurden, kann die erste Testkonvertierung durchgeführtwerden. Dabei sollte darauf geachtet werden, dass schon beim erstenVersuch im Bereich Export/Import bekannte Performance-Optimie-rungen angewendet werden. Die folgende Liste liefert einen Über-blick der Schritte:

� Aufbau des Sandbox-Systems als Kopie von PRD

Schritte zur Sand-box-Konvertierung

Im Idealfall entspricht die Hardware des Sandbox-Systems bereitsbei diesem ersten Test in etwa der Hardware des PRD-Systems. Indiesem Fall kann man die Ergebnisse der Scan-Zeiten und dieExport-/Import-Zeiten am besten auf das PRD-System übertragen.

In der Praxis steht jedoch meistens keine vergleichbare Hardwarezur Verfügung, sodass zunächst der Vorgang der Konvertierungselbst getestet wird – ohne den Fokus auf die Laufzeiten. Bei gro-ßen Systemen kann dies aber zu sehr langen Laufzeiten führen,sodass der gesamte Test sehr lange dauert.

� Vorbereitungsschritte zur Unicode-KonvertierungDen Hauptbereich für die Vorbereitung der Unicode-Konvertie-rung eines MDMP-Systems bildet hier Transaktion SPUMG. Esmuss entsprechend Zeit für die Scans eingeplant werden, die dasSystemvokabular aufbauen, für die Bearbeitung des Vokabularsund auch für die Reprocessing-Scans. Die Laufzeiten der Scansbewegen sich bei großen Systemen im Bereich von einigen Tagenbis hin zu mehreren Wochen. Der Scan ohne Sprachkennzeichenbenötigt in der Regel die längste Zeit, aber auch der Reprocessing-Scan kann einen prozentual großen Anteil in Anspruch nehmen.


250


Hinzu kommt die Bearbeitungszeit für die Zuweisung der Vokabu-lareinträge. Da das im Sandbox-System gepflegte Systemvokabulardie Grundlage für die spätere Konvertierung aller vorhandenenSysteme bildet, sollte dieser Vorgang gleich zu Beginn mit dernötigen Sorgfalt ausgeführt werden.

� Export und ImportIn diesen Bereich fallen die Tests bezüglich der Laufzeitoptimie-rung. Wenn Transaktion SPUMG bereits ausreichend getestetwurde, ist es nicht erforderlich, diese Transaktion selbst als Vorbe-reitungs-Scan immer wieder auszuführen, da dies immer wieder –im schlechteren Fall – mehrere Wochen dauern kann. Alternativkann ein Backup nach Beendigung der SPUMG-Arbeiten als Aus-gangssystem verwendet werden.

� Durchführung der Post-KonvertierungsaufgabenTransaktion SUMG deckt die wichtigsten Reprocessing-Schritteab. Anhand dieser Transaktion kann der Aufwand zur manuellenReparatur abgeschätzt werden. Gegebenenfalls können hierbereits Reparatur-Hints erzeugt werden.

� TestphaseNachdem die Unicode-Konvertierung abgeschlossen ist, folgenTests der Anwendungen, z.B. kann ein Teil der kundeneigenenABAP-Objekte getestet werden. Wenn möglich, sollten hier auchInterface-Tests durchgeführt werden. Im Normalfall ist dies in vol-lem Umfang allerdings erst im QAS-System möglich, da im Sand-box-System die Interfaces erst aufgesetzt werden müssen.

Grundsätzlich gilt allerdings: Alle Tests, die bereits im Sandbox-System gemacht werden können, sollten dort auch durchgeführtwerden. Je früher ein Problem entdeckt wird, desto mehr Zeitbleibt zur Behebung.

� Analyse und Ergebnisse der Sandbox-KonvertierungDie Sandbox-Konvertierung liefert Ergebnisse zur R3load-Lauf-zeitoptimierung, Vorgehensweise und den Scan-Laufzeiten derTransaktionen SPUMG und SUMG sowie für erste Unicode-Testsnach der Konvertierungsphase. Anhand dieser Ergebnisse mussnun entschieden werden, ob weitere Sandbox-Konvertierungs-durchgänge notwendig sind und wann die nächsten Systeme inder Landschaft konvertiert werden sollten. Entsprechend erfolgteine Verfeinerung und Anpassung des Projektplans an die weitereVorgehensweise.


251


� Wiederholung der Sandbox-Konvertierung (abhängig von denErgebnissen der vorherigen Konvertierung)Die Sandbox-Konvertierung sollte so lange wiederholt werden, bisdie Anforderungen an die Ausfallzeit erfüllt werden. Parallel dazukann bereits mit der Konvertierung des Qualitätssicherungssys-tems bzw. Entwicklungssystems begonnen werden.

Konvertierung des Entwicklungs- bzw. Qualitätssicherungs-systems

Die Konvertierung des Entwicklungs- bzw. Qualitätssicherungssys-tems erfolgt analog zu der des Sandbox-Systems. Unter Umständenkönnen hier noch längere Ausfallzeiten im Vergleich zum Produktiv-system akzeptiert werden.

Aussagekräftige Interface- und Integrationstests sind in der Regelerst auf dem Qualitätssicherungssystem möglich. Ein parallelerVorab-Test von Transaktion SPUMG auf dem PRD-System zu diesemZeitpunkt stellt sicher, dass die Scan-Dauer dieser Transaktion nichtunterschätzt wird.

Konvertierung des Produktiv-Systems

Faktoren, die den Aufwand einer Unicode-Konvertierungbeeinflussen

Basierend auf den Erfahrungen aus dem Sandbox-System sowie derEntwicklungs- und Qualitätssicherung kann die Konvertierung desProduktivsystems erfolgen. Wichtig ist, dass die Konvertierung unterexakt den in den Testsystemen herrschenden Bedingungen durchge-führt wird. Beispielsweise sollte der Patch-Level des Kernels (insbe-sondere die R3load-Version) identisch mit dem in den anderen Sys-temen sein.

Der erste Tag bzw. die erste Woche nach der Konvertierung erfor-dert in der Regel besondere Aufmerksamkeit, da es in einigen Berei-chen Probleme geben kann. Dies sollte in der Planung berücksichtigtwerden.

4.2.2 Rahmenbedingungen eines Konvertierungsprojektes

Mögliche Gründe für eine Unicode-Konvertierung

Am Anfang eines Unicode-Projektes gibt es eine Reihe von typischenFragen, die in diesem Abschnitt geklärt werden sollen. Die folgende


252


Auflistung zeigt zunächst mögliche Gründe für eine Unicode-Konver-tierung:

� vorhandenes MDMP-System mit gewünschtem Upgrade aufmySAP ERP 2005 (siehe SAP-Hinweis 79991)

� Englisch soll als zentrale Logon-Sprache für alle Länder bzw. Spra-chen möglich sein

� der Datenaustausch zwischen MDMP und Unicode verursachtProbleme

� es sollen Java-Technologien (z.B. ESS/MSS auf mySAP ERP 2004)im MDMP-Umfeld verwendet werden

� Notwendigkeit des Roll-outs in andere Länder, die nicht von derim System existierenden Non-Unicode-Lösung abgedeckt werden

� Systemkonsolidierung von Systemen mit unterschiedlicher Code-page-Konfiguration

� Roll-out in Länder, deren Zeichen in Non-Unicode nicht unter-stützt werden (z.B. Arabisch, Vietnamesisch)

� Unterstützung von Dialekten (z.B. Französisch-Kanada)

� die Darstellung bestimmter Zeichen ist notwendig (z.B. des €-Zei-chens), die in Non-Unicode nicht unterstützt werden

� Internet-Anbindung (z.B. eines Webshops)

� starke Java-Integration des Systems

Dauer einesKonvertierungs-

projektes

Die Projektdauer wird bei einer Unicode-Konvertierung ähnlich wiebei einem Upgrade durch zahlreiche Faktoren bestimmt. Die Haupt-bereiche sind in Tabelle 4.1 dargestellt. Zusätzlich hängt die Dauernatürlich auch von der Anzahl der zur Verfügung stehenden Ressour-cen und deren Wissensstand ab.

Faktoren

Aufwand

Leicht Mittel Schwierig

verwendete Spra-chentechnologie

Single-Codepage asiatische Codepage

MDMP

verwendete SAP-Lösung

SAP Web AS (Standalone)

mySAP ERP oder SAP R/3 Enterprise

mySAP CRM mit Mobile Sales

Tabelle 4.1 Aufwand einer Unicode-Konvertierung


253


Als Minimalwert für eine Konvertierung einer Drei-System-Land-schaft können etwa vier Wochen Projektlaufzeit angenommen wer-den. Im Schnitt dauern diese Projekte etwa drei bis vier Monate. Beisehr großen MDMP-Systemen mit sehr vielen kundeneigenen ABAP-Objekten und/oder Schnittstellen zu anderen MDMP-Systemen kanndie Laufzeit mitunter auch mehr als ein Jahr betragen.

Kosten einer Unicode-Konvertierung

Auch eine Kostenabschätzung ist abhängig von den in Tabelle 4.1 auf-gezählten Faktoren. Außerdem müssen in diesem Bereich die zusätz-lichen Hardware-Anforderungen berücksichtigt werden. Aufwendun-gen für Tests und für das Anpassen kundeneigener Reports könnenunter Umständen einen großen Teil des Gesamtbudgets ausmachen.

Benötigte Spezialisten

Zusätzlich erfordert ein Unicode-Projekt Know-how im BereichABAP Enabling sowie im Interface-Bereich, hier werden Spezialistenaus dem Programmierumfeld und Mitarbeiter mit SAP NetWeaver-Kenntnissen benötigt. Transaktion SPUMG wird in der Regel durchSAP NetWeaver-Experten ausgeführt. Zur Bearbeitung des System-vokabulars sind jedoch auch Personen erforderlich, die die jeweili-gen Sprachen gut beherrschen. Das Ex-und Importverfahren und dieOptimierung ist vergleichbar mit dem Upgrade und erfordert wie-

Faktoren

Aufwand

Leicht Mittel Schwierig

Datenbankgröße Datenbank < 300 GB

Datenbank zwi-schen 300 GB und 1.500 GB

Datenbank > 1.500 GB

akzeptierte Ausfallzeit

Ausfallzeit > 4 Tage

Ausfallzeit von 2 bis 4 Tagen

Ausfallzeit < 2 Tage

Hardware-Eigenschaften

sehr schnelle Hardware

mittlere Hardware

langsame Hardware

ABAP-Objekt-anpassung

geringe Anzahl von Objekten

mittlere Anzahl von Objekten

hohe Anzahl von Objekten

Konvertierungs-methode

Standard Split von großen Tabellen

IMIG/CU & UC

SAP-Interfaces Unicode-Systeme Single-Code-page-Systeme

MDMP-Systeme

Non-SAP-Interfaces

Unicode-Systeme Single-Code-page-Latin-1

asiatische Codepage

Tabelle 4.1 Aufwand einer Unicode-Konvertierung (Forts.)


254


derum technisches Wissen. Die Tests liegen in der Regel im Verant-wortungsbereich der Anwendung.

Konvertierungs-varianten bei einer

Drei-System-Landschaft

Abbildung 4.2 zeigt zwei mögliche Szenarien einer Unicode-Konver-tierung: Links ist eine Konvertierung mit Sandbox dargestellt, rechtssehen Sie ein Szenario ohne Sandbox, wobei das Qualitätssiche-rungssystem vor dem Entwicklungssystem konvertiert wird.

Abbildung 4.2 Mögliche Konvertierungsszenarien einer Drei-System-Landschaft

Sandbox-Konvertierung

Die Konvertierung mit Sandbox ist die von SAP empfohlene Vorge-hensweise bei einer Unicode-Konvertierung. Dies beantwortet abernoch nicht die Frage, in welchem Fall eine Sandbox-Konvertierungauf jeden Fall notwendig ist. In den folgenden Fällen ist eine Sand-box-Konvertierung kaum zu vermeiden:

� Kritische Anforderungen bzgl. Ausfallzeit bzw. Konvertierungvon sehr großen SystemenKonvertierungslaufzeiten lassen sich nur auf Sandbox-Systemenmit vergleichbaren Hardware-Bedingungen aussagekräftig testen.Extrapolationen der Laufzeiten von sehr schwachen Servern aufProduktivumgebungen sind extrem unsicher. Folglich steigt dieWahrscheinlichkeit von Überraschungen während der Produktiv-konvertierung, wenn nicht ausreichend unter vergleichbarenBedingungen getestet wurde.

D Q P

S

D Q P

D Q P

S

D Q P

D Q P

D

D Q P

D Q P

AufbauSandbox

KonvertierungSandbox (n-mal)

KonvertierungEntwicklung

KonvertierungQAS

D Q P

KonvertierungPRD

Konvertierung mit Sandbox Konvertierung ohne Sandbox

KonvertierungQAS

KonvertierungDEV

KonvertierungPRD

D Q P

X Non-Unicode

X Unicode

D DEV

Q QAS

P PRD

S SBX

Q P


255


� MDMP-KonvertierungIm Falle einer MDMP-Konvertierung empfiehlt SAP unbedingteine Testkonvertierung auf eine Kopie des Produktivsystems. Diesist die einzige Möglichkeit, die Konvertierung vollständig zu testen.

� Kombinierte Upgrade- und Konvertierungslösungen Grundvoraussetzung für komplexere Lösungen wie z.B. CU & UC(siehe Abschnitt 3.3) ist der Aufbau von getrennten Testsystemen.Im Fall von TU & UC muss sowieso ein Twin-System aufgebautwerden.

� QAS- vor der DEV-KonvertierungEs ist durchaus überlegenswert, ob das QAS-System vor dem Ent-wicklungssystem konvertiert werden soll. Ein »richtiger« Test derInterfaces ist häufig nur auf dem QAS-System möglich. Problememit Interfaces sollten aber schnell identifiziert werden, da eineBehebung unter Umständen aufwändig werden kann. Für einenaussagekräftigen Integrationstest gilt im Prinzip die gleiche Aussage.

� Konvertierung mit »Wartungslandschaft«Analog zum Upgrade existiert das Szenario der Non-Unicode-War-tungssysteme (DEV und QAS), die als Support für das Non-Uni-code-Produktiv-System während der Unicode-Konvertierung die-nen. Damit wird sichergestellt, dass ein kritisches Problem, dassich unter Non-Unicode anders als unter Unicode verhält, zügigbehoben werden kann.

4.2.3 Vergleich zu Upgrade-Projekten und OS/DB-Migration

Zum Thema Upgrade gibt es sehr viel Dokumentation und die meis-ten Kunden haben zumindest ein Upgrade-Projekt bereits durchge-führt. Einige Kunden haben auch Erfahrung im Bereich OS/DB-Mig-ration gesammelt. Mit diesem Hintergrund kann der folgendeVergleich einer Unicode-Konvertierung mit dem Upgrade und derOS/DB-Migration durchaus hilfreich sein.

� FunktionalitätFunktionale Ände-rungen bei einer Unicode-Konver-tierung und beim Upgrade

Bei einem Upgrade können sich Applikationen grundlegendändern, sodass vorhandene Kundenentwicklungen angepasst wer-den müssen. Bei einer Unicode-Konvertierung bzw. OS/DB-Mig-ration ändert sich das System applikationsseitig nur minimal.


256


� SystemausfallzeitVergleich der

Downtime beieiner Unicode-

Konvertierung undbeim Upgrade

Die Abhängigkeit der Ausfallzeit für die Konvertierung des Pro-duktivsystems von der Datenbankgröße ist bei einer Unicode-Konvertierung wesentlich größer. Beim Upgrade wird dieseAbhängigkeit in der Regel durch eine bei einem großen Systemtendenziell bessere Hardware kompensiert. Dieser Trend lässt sichnatürlich auch für Unicode-Konvertierungen feststellen, allerdingsmuss hierzu entsprechender Aufwand für die Performance-Opti-mierung aufgewendet werden.

Die Ausfallzeit einer Unicode-Konvertierung ist eher vergleichbarmit der Ausfallzeit bei einer OS/DB-Migration – allerdings ist derCPU-Bedarf im Falle einer Unicode-Konvertierung signifikanthöher, da z.B. bei komprimierten Cluster-Tabellen viele rechenin-tensive Operationen ausgeführt werden müssen (die Daten wer-den dekomprimiert, konvertiert und dann wieder komprimiert).

� Vergleich zu UCCHECK- und SPUMG-AnpassungenNotwendige Uni-

code-AnpassungenDie Anpassungen im Bereich der Kundenentwicklungen (über dieTransaktionen SPAU bzw. SPDD) lassen sich noch am ehesten mitden UCCHECK-Anpassungen vergleichen; allerdings zeigt Trans-aktion UCCHECK direkt, wo Objekte verändert werden müssen.Außerdem lassen sich die Objekte schon vor der Unicode-Konver-tierung im Non-Unicode-System anpassen. Das gilt für einUpgrade im Regelfall nicht. Transaktion SPUMG besitzt im Falleeines MDMP-Systems keinen vergleichbaren Schritt bei einemUpgrade. Ein Scannen der gesamten Datenbank und die anschlie-ßende Pflege der Ergebnisse sind bei einem Upgrade nicht not-wendig.

Anpassungen in den Interfaces benötigen bei einer Unicode-Kon-vertierung insbesondere bei einem MDMP-System besonderesAugenmerk (siehe Kapitel 3). Im Falle einer OS/DB-Migrationmüssen Anpassungen in kundeneigenen ABAP-Objekten, diedatenbankspezifische Befehle enthalten, gemacht werden (z.B.Native SQL).

� Release-EinschränkungenRelease-

Einschränkungenbei einer Unicode-

Konvertierung

Bei einem Upgrade ändert sich definitionsgemäß das Release desSAP-Systems nach Beendigung des Prozesses. In der Regel ist einUpgrade mit den meisten noch unterstützten Releases im Quell-system möglich.


257


Eine Unicode-Konvertierung wird dagegen standardmäßig aufeinem festen Release durchgeführt. Es gibt Einschränkungensowohl auf der Unicode-Seite (R/3-Releases <= 4.6C unterstützenUnicode nicht) als auch auf der Non-Unicode-Seite (MDMP bzw.Blended-Codepages werden ab mySAP ERP 2005 nicht mehrunterstützt).

Bei der OS/DB-Migration gibt es nur sehr wenige Release-Ein-schränkungen. In der Regel lässt sich eine Migration mit einembeliebigen unterstützten Release durchführen. Ebenso wie bei derUnicode-Konvertierung ändert sich das Release während der Mig-ration nicht.

� Entwicklungsstopp während des ProjektesWann ist ein Ent-wicklungsstopp notwendig?

Bei einem Upgrade ist das Transportieren zwischen den verschie-denen Releases nicht unterstützt. Insofern ist ein Entwicklungs-stopp während des Upgrade-Projektes ohne getrennte Wartungs-landschaft kaum zu vermeiden.

Im Falle einer Unicode-Konvertierung gilt, dass ein Transport zwi-schen Unicode und Non-Unicode durchaus möglich ist (mit Ein-schränkungen bzgl. MDMP). Das bedeutet, dass die Notwendig-keit eines Entwicklungsstopps nicht zwingend erforderlich ist. DieEmpfehlung von SAP ist aber, die Anzahl der Projekte währendder Unicode-Konvertierung möglichst zu minimieren, da esdurchaus Unterschiede zwischen Unicode- und Non-Unicode-Sys-temen gibt (z.B. im Interface-Bereich).

� FrequenzWie oft muss eine Unicode-Konver-tierung durchge-führt werden?

Eine Unicode-Konvertierung wird genau einmal pro Systemdurchgeführt. Danach ist kein weiteres Projekt nötig. Ein Upgradedagegen wiederholt sich im Normalfall regelmäßig. Eine OS/DB-Migration liegt irgendwo dazwischen, sie ist für die meisten Kun-den aber auch eine eher ungewöhnliche Aufgabe und wiederholtsich pro System nicht oft.

� End-User-TrainingWas muss beim End-User-Training beachtet werden?

Bei einem Upgrade müssen die End-User häufig trainiert werden,da sich die Funktionalität ändern kann.

Bei einer Unicode-Konvertierung gibt es nur sehr wenig Bereiche,in denen der Benutzer tatsächlich bemerkt, dass technisch eineVeränderung stattgefunden hat. Beispiele hierfür sind der Word-Editor für die SAPscript-Bearbeitung und der Up- bzw. Download,


258


wo unter Umständen eine Ziel-Codepage angegeben werdenmuss. Falls die Unicode-Konvertierung aber mit einem Upgradeverbunden wurde, muss natürlich ein entsprechendes Trainingder End-User erfolgen.

4.2.4 Konvertierung komplexer Landschaften

In welcher Reihen-folge sollen SAP-Systeme in kom-

plexen Landschaf-ten Konvertiert

werden?

Viele Kunden verwenden neben einer ERP-Applikation noch zahlrei-che andere SAP-Applikationen. Diese sind meist miteinander ver-bunden und es stellt sich zunächst die Frage, in welcher Reihenfolgedie verschiedenen Systeme konvertiert werden sollen.

In der Regel ist es nicht möglich, alle Systeme an einem Wochenendezu konvertieren, da hiermit ein extrem großer Aufwand verbundenwäre. Aber das Risiko, dass die gesamte Konvertierung an einemWochenende fehlschlägt, ist bei einem solchen »Big Bang« ebenfallssehr hoch: Wenn man annimmt, dass fünf miteinander eng verbun-dene Produktivsysteme an einem Wochenende konvertiert werdensollen, so darf es bei keinem System ein größeres, nicht sofort beheb-bares Problem geben, da ansonsten alle Systeme zurückgesetzt wer-den müssen.

Kriterien zur Kon-vertierung komple-

xer Landschaften

Anhand der folgenden Kriterien sollte kundenspezifisch evaluiertwerden, welche die optimale Reihenfolge ist:

� Unicode-Fähigkeit der verschiedenen SAP-Applikationen(Releases)Voraussetzung für die Unicode-Konvertierung ist die Unicode-Fähigkeit des Releases. Ist ein System beispielsweise auf SAP R/34.6C, kann die Konvertierung erst nach dem Upgrade erfolgen.

� Anforderungen bzgl. Sprachen bzw. Ländern in den verschiede-nen SystemenSysteme, die Daten von mehreren »alten Codepages« abdecken(müssen), sollten bevorzugte Kandidaten für eine Unicode-Kon-vertierung sein. Systeme ohne entsprechende Anforderungen(reine Single-Codepage-Systeme) können zu einem späteren Zeit-punkt konvertiert werden.


259

Release-Wechsel und Unicode-Konvertierung 4.3

� Minimierung der Schnittstellen zwischen MDMP- und Unicode-SystemenDie in Abschnitt 3.5 beschriebene Schnittstellenproblematik zwi-schen Unicode- und MDMP-Systemen führt zu dem sehr wichti-gen Kriterium, die Anzahl der in der Systemlandschaft vorhande-nen MDMP-Systeme so gering wie möglich zu halten.

� Upgrade-Planungen bzgl. MDMP-Systemen, die auf SAP Net-Weaver 2004s basierenMit SAP NetWeaver 2004s ist MDMP nicht mehr unterstützt(siehe SAP-Hinweis 79991). Deshalb ist bei Upgrade-Planungenauf entsprechende Lösungen eine Unicode-Konvertierung mit ein-zuplanen.

� KonsolidierungsplanungenBei geplanten Systemzusammenführungen, insbesondere wennunterschiedliche Codepages verwendet werden, bietet sich einWechsel auf Unicode an.

� Datenbankgrößen der verschiedenen Systeme und schnell wach-sende DatenbankenDer Aufwand einer Unicode-Konvertierung hängt stark von derDatenbankgröße ab. Falls es innerhalb der Landschaft Systemegibt, die ein sehr hohes Wachstum besitzen, so sollte überlegtwerden, dieses System eher zu konvertieren.

� Geplante Projekte und regelmäßige AktionenEine Unicode-Konvertierung sollte zu einer »projektarmen« Zeitgeschehen. Idealerweise sollten vorhandene Projekte auf die Zeitnach der Konvertierung verschoben werden. Aber es müssen auchAktionen wie z.B. der Jahresabschluss mit berücksichtigt werden.Eine Unicode-Konvertierung kurz vor dem Jahresabschluss ist inder Regel problematisch.

4.3 Release-Wechsel und Unicode-Konvertierung

Wie können Upgrade und Uni-code-Konvertie-rung miteinander kombiniert wer-den?

Das Upgrade (Release-Wechsel) und die Unicode-Konvertierung sindjeweils Projekte, in deren Verlauf umfangreiche Tests der Anwen-dungen nötig sind. Obwohl dies zwei logisch unabhängige Schrittesind (siehe Abbildung 3.3), stellt sich dennoch die Frage, inwieweitsich die beiden Aufgaben verbinden lassen.


260


In Abschnitt 3.3 wurden bereits entsprechende Kombinationsverfah-ren beschrieben. Letztere sind insbesondere im Zusammenhang miteinem Upgrade von einem nicht unicodefähigen Release mit MDMPauf mySAP ERP 2005 von Interesse, da in diesem Ziel-ReleaseMDMP nicht mehr unterstützt ist (siehe SAP-Hinweis 79991).

Zusammengefasst gibt es folgende Möglichkeiten der Einbindungvon Konvertierungsaufgaben in ein Upgrade:

Weitestgehendlogische Trennung

von Upgradeund Unicode-Konvertierung

� Separate ProjekteDas Upgrade wird vollständig getrennt von der Unicode-Konver-tierung durchgeführt.

� Berücksichtigung der ABAP-Objekte während des UpgradesDie Anpassung der ABAP-Objekte an die verschärften Unicode-Syntax-Regeln wird im Upgrade mit berücksichtigt. Separate Inte-grationstests für die Änderungen der ABAP-Objekte in Non-Uni-code sind nicht notwendig.

Vor- und Nach-teile der Verbin-

dung von Upgradeund Unicode-

Konvertierung ineinem Projekt

� Upgrade und Unicode-Konvertierung in einem Projekt, aber angetrennten WochenendenEs ist möglich, die Konvertierung und das Upgrade in einem Pro-jekt durchzuführen, für die Konvertierung des Produktivsystemsjedoch ein separates Wochenende auszuwählen. Dies bedeutet –bei der Annahme, dass das Upgrade vor der Konvertierunggemacht wird –, dass Tests sowohl im Non-Unicode- als auch imUnicode-System durchgeführt werden müssen, da in diesem Fallja das Non-Unicode-System auf dem neuen Release »live« geht.

Vorteile wären hier beispielsweise, dass ein Sandbox-Systemsowohl für das Upgrade als auch für die Konvertierung verwendetwerden kann und dass Tests zwar zweimal, aber ansonsten iden-tisch kurz hintereinander durchgeführt werden können.

� Upgrade und Unicode-Konvertierung am gleichen WochenendeDas Hauptkriterium zur Entscheidung, ob die Konvertierung unddas Upgrade an einem Wochenende durchführbar sind, ist dieLaufzeit der beiden Prozeduren. Falls eine Unicode-Konvertierungbei Ausschöpfung aller möglichen Optimierungsmethoden bereits30 bis 40 Stunden Ausfallzeit in Anspruch nimmt, wird ein kom-biniertes Verfahren in der Regel nur in den seltensten Fällen sichmit allen Vor- und Nachbereitungen in 48 Stunden durchführenlassen. Folglich muss entweder eine verlängerte Ausfallzeit akzep-


261

Release-Wechsel und Unicode-Konvertierung 4.3

tiert werden, oder die in den vorherigen Punkten beschriebeneAlternative gewählt werden.

Eine kombinierte Lösung bedeutet gleichzeitig eine starke Erhö-hung der Komplexität des Projektes. Das Vorgehen bei einemalleinigen Upgrade ist recht gut und umfangreich dokumentiertund auch für die Durchführung einer separaten Unicode-Konver-tierung existieren Unterlagen. Eine Zusammenlegung der beidenProjekte erfordert eine Detailplanung, wofür Stand heute nochwenig Informationsmaterial existiert. Ein Beispiel wäre dieBehandlung der ABAP-Objekte bei einem Upgrade mit Konvertie-rung unter Start-Release SAP R/3 4.6C.

� Combined Upgrade & Unicode ConversionVerbindung des Upgrades von SAP R/3 4.6C mit einer Unicode-Konvertierung

Diese CU & UC-Methode ist primär für (MDMP-)Kunden entwi-ckelt worden, die als Quell-Release SAP R/3 4.6C haben und eintechnisches Upgrade auf mySAP ERP 2005 anstreben. In SAP-Hin-weis 928729 werden die unterstützten Releases und Einschrän-kungen genauer beschrieben.

Ein wesentlicher Bestandteil dieser Technik ist die Verwendungvon Transaktion SPUM4, die ein Äquivalent zu TransaktionSPUMG unter SAP R/3 4.6C darstellt (siehe Abschnitt 3.3.2). Diesist notwendig, da das Prinzip der Transaktionen SPUMG oderSPUM4 vorsieht, die Transaktion während des Produktivbetriebesonline durchzuführen. Da sich die Laufzeiten von TransaktionSPUMG für MDMP-Kunden zumindest im Bereich von Tagenbewegen, ist die Durchführung von Transaktion SPUMG im Ziel-Release während der Ausfallzeit nicht möglich. Deshalb wurdeSPUMG in SAP R/3 4.6C als SPUM4 implementiert, sodass dieOnline-Durchführung schon mit diesem Release möglich ist.

Im Gegensatz dazu ist beispielsweise das Unicode-Enabling(Transaktion UCCHECK) unter SAP R/3 4.6C nicht möglich. DieserVorbereitungsschritt muss auf einem Sandbox-System auf einemunicodefähigen Release (auf Non-Unicode oder Unicode) durchge-führt werden. Die Ergebnisse können dann nach erfolgtemUpgrade ins Produktiv-System transportiert werden.

Abbildung 4.3 zeigt schematisch eine mögliche Vorgehensweisebeim CU & UC-Verfahren. Im Sandbox-System (SBX) musszunächst das Unicode-Enabling erfolgen, dessen Ergebnisse dannim Produktivsystem (PRD) nach erfolgtem Upgrade verwendet


262


werden können. Das Upgrade und die Unicode-Konvertierung imSandbox-System können auch alternativ im ersten Schrittzunächst voneinander getrennt werden, sodass die UCCHECK-Aktivitäten auf dem Non-Unicode-System erfolgen können.

Abbildung 4.3 Exemplarische Vorgehensweise bei CU & UC

Verbindungvon Upgrade undKonvertierung fürR/3-Systeme mit

Release < 4.6C

� Twin Upgrade & Unicode ConversionCU & UC lässt sich nicht für Quell-Systeme < SAP R/3 4.6C ver-wenden. Um auch für diese Kunden eine Lösung anzubieten,wurde die Methode TU & UC entwickelt. Hierbei wird ein paralle-les Twin-System als Kopie des Produktivsystems aufgebaut und eswird ein Upgrade ohne Unicode-Konvertierung durchgeführt(siehe Abbildung 4.4).

Abbildung 4.4 Exemplarische Vorgehensweise bei TU & UC

Auf dieser Kopie kann man jetzt Transaktion SPUMG laufen las-sen. Die Ergebnisse werden dann zum Produktiv-Upgrade vor der

PRD

SBX

4.6C

SPUM4

ERP 2005

UCCHECK

ERP 2005

Upgrade und Konvertierung

Upgrade und Konvertierung

4.6C

SPUM4PREPARE

Kopie

SUMG

4.6C

Unicode

Non-UnicodeZeit

Ergebnisse

PRD

4.6BTWIN

4.6B

ERP 2005

UCCHECK+SPUMG

ERP 2005

Upgrade

4.6B

Kopie

Upgrade undKonvertierung

SUMG

Unicode

Non-UnicodeZeit

Ergebnisse


263

Systemkonsolidierung 4.4

Unicode-Konvertierung in das Produktivsystem transferiert unddort verwendet. Hierbei existiert natürlich ein Delta (Tabellen-Einträge, die nach dem Aufbau des Twin-Systems ins PRD gekom-men sind), das umso größer ist, je älter die Systemkopie des Pro-duktivsystems ist. Folglich muss damit gerechnet werden, dass dieAufgaben nach der Konvertierung (SUMG) mehr Zeit in Anspruchnehmen.

In SAP-Hinweis 959698 werden die unterstützten Releases undEinschränkungen von TU & UC genauer beschrieben.

4.4 Systemkonsolidierung

Vereinfachung der Systemlandschaft

Zwecks Vereinfachung der Systemlandschaft gibt es bei vielen Kun-den Bestrebungen, die Anzahl der existierenden Systeme zu verrin-gern. Eine Möglichkeit besteht darin, Systeme mit ähnlicher Ausprä-gung in der Anwendung, die allerdings für andere Länder aufgebautwurden, in ein bestehendes System zu integrieren. Hier bietet es sichan, als Grundlage ein Unicode-System zu verwenden.

In der Regel handelt es sich bei den zu migrierenden Systemen umNon-Unicode-Systeme und eine Konvertierung der Daten währendder Migration wäre wünschenswert; meist ist dies auch möglich.MDMP-Systeme bilden hier wieder eine Ausnahme, da die Konver-tierung nicht so einfach wie bei einem Single-Codepage-System ist.Zurzeit kann die SPUMG-Logik nicht für eine Datenmigration ver-wendet werden.

Client-Migration-Server

Es gibt seitens der SAP System Landscape Optimization Planungenfür Tools, die es ermöglichen, von SAP R/3 4.6C (Non-Unicode) inein mySAP ERP 2005 (Unicode) zu migrieren. Es werden hier alsodrei Schritte in einem gemacht: Ein Upgrade, eine Unicode-Konver-tierung und eine Systemzusammenführung. Die hierbei verwendeteTechnik wird Client-Migration-Server (CMIS) genannt. Nähere undaktuelle Informationen hierzu finden Sie im SAP Service Marketplace(http://service.sap.com/slo).


264


4.5 Zusammenfassung

Der Schwerpunkt dieses Kapitels lag auf der Planung der Unicode-Konvertierung einer komplexen Systemlandschaft. Eine Neuinstalla-tion ist dabei noch relativ einfach, da sie sich kaum von der Installa-tion eines Non-Unicode-Systems unterscheidet. Bei der Konvertie-rung einer Drei-System-Landschaft gibt es dagegen schon vieleverschiedene Möglichkeiten, Unicode zu implementieren.

Eine Aufwandsabschätzung des Unicode-Projektes ist nicht ohnegenaue Kenntnis von diversen Faktoren möglich. Hier spielen dieDatenbankgröße, die mögliche Verwendung von MDMP, die Anzahlder selbst geschriebenen Programme und die Art und Anzahl derInterfaces eine große Rolle. Ein Vergleich der Unicode-Konvertie-rung mit einem Upgrade-Projekt verdeutlicht, dass je nach Randbe-dingungen das Unicode-Projekt durchaus ähnliche Zeiträume wieder Release-Wechsel in Anspruch nehmen kann. Ein kombiniertesUpgrade- und Konvertierungsverfahren steht für Kunden zur Verfü-gung, jedoch sollte die Komplexität eines solchen Projektes nichtunterschätzt werden.


327

Index

#Ersatzzeichen 180

1:N-Relation 2867-Bit-ASCII 17

A

ABAP 135ABAP Editor 136ABAP Enabling 120ABAP Workbench 136abap/unicode_check 155ABAP-Programm

unicodefähig 136ABAP-Programmierung 140ABAP-Stack 168, 176ABAP-Textpool-Einträge 277Adobe Document Services 231Adressversionen 284, 285ALE 143, 319ALE-Eingangsverarbeitung 198ALE-Kommunikationsszenario 211ALE-Nachrichtentyp 196, 202, 211

multilingual 211ALE-Prototyp 196ALE-Standardtransfer 196ALE-Unicode-Szenario 200, 202, 211ALE-Verteilungsmodell 197Alignment gaps 141Ambiguous-Blended-Codepage 41, 74Anmeldesprache 182ANSI 319API 319Append-Struktur 121, 147Applikationsserver 183, 319Arbeitsvorrat 273Archivierung 248ASCII 170

German 320asiatische Double-Byte-Sprachen 138,

168asiatische Sprachen 165asynchrone Übertragung 319Auffüll-Logik 280Auffüllsprache 268, 282

Auffüllung 279Aufwandsabschätzung 247Aufwandskategorie 230Ausfallzeit 260Ausrichtungslücke 141

B

Backup 319BAdI 156Bandbreite 319Batch 319BCP → Blended-CodepageBDC 319BDocs 188, 191, 213Benutzerzeit 15BIDI 319BIDI-Technologie 31Big Bang 258Big Endian 53, 319Big Five 36, 298Binärdatei 319Bit Option 180Black Box 143Blended-Codepage 115, 117, 118Blended-Codepage-System 40BOM 319BRIC-Länder 115BTF 319Buchstaben 28Business Address Services 285Business Server Pages 56Byte 319Byte-swapped 319

C

Cascading Font Generator 239Cascading-Fonts 112, 239Case

lower 319upper 319

CBL 319CGI 319Character Composition 35


328

Index

Character Encoding Form 319Character Encoding Scheme 319Character Rendering 229Character Set 319charlen 168CJK 320CJKV 320CL_ABAP_CHAR_UTILITIES 151CL_ABAP_CONTAINER_UTILITIES 153CL_ABAP_CONV_IN_CE 153CL_ABAP_CONV_OUT_CE 153CL_ABAP_CONV_X2X_CE 153CL_ABAP_LIST_UTILITIES 153CL_NLS_STRUC_CONTAINER 146CL_NLS_STRUC_CONTAINER_OFFS

146CL_NLS_STRUC_CONTAINER_SNAME

146Client-Migration-Server 263CMIS 263CMOD 224Code Inspector 154, 159Codepage 16, 27, 28, 29, 320

Big Five 298GB2312 298ISO 8859 293, 294, 295, 296ISO Latin-11 297JISX208 297KSC5601 298Microsoft 1250 294Microsoft 1251 295Microsoft 1252 294Microsoft 1253 296Microsoft 1254 296Microsoft 1255 296Microsoft 1257 295Microsoft 874 297

Codepage-Scanner 70Codepage-Tabellen 293Codepoint 28Common Character Set 17, 21Container-Alignment 143, 147, 206

bei asiatischen Double-Byte-Sprachen 205

Containerproblem 144Containertechnik 143, 206CORBA 51Coverage Analyzer 154, 157CPU 320

CU & UC 116, 119, 261Customizing

sprachabhängig 279Customizing-Includes 147

D

Datenbank-Codepage 29Datentransfer

multilingual 176Datentyp

LANG 176Datentypen 170

nicht zeichenartige 138numerische 139zeichenartige 138, 139zeichenbasierte 171

Datenübertragung 25DBCS 320DDIC-Attribut

Textsprache 74Deep Data Types 170Default Set 299Delta-Problematik 92Dialektsprachen 228Distributionsmonitor 104DMEE 181Double Byte Character Set 320Double-Byte 34, 40Double-Byte-Codepage 17, 293Double-Byte-Sprachen 138, 143, 206Drittanbieter-Software 244Drucken

im Unicode-System 110Druckertreiber 232Dynamic-Codepage-Switch-System 43

E

EBCDIC 29, 320eCATT 320ECMAScript 51EDID4-SDATA 143EDIFACT 320Eingabemethode 231Eingangsverarbeitung 200, 209, 210Encoding Form 320Encoding Scheme 320Endianess 54, 165, 169


329

Index

End-User-Training 257Enterprise Services Architecture 55Enterprise SOA 55, 56Entwicklungsstopp 257Ersatzzeichen 151, 180Erweiterungskategorie 148EUC 320Evaluierungsphase 245Expansion

in neue Länder 289Export 95Export-Control-Tabelle 80Extraktoren 188Extraktorjobs 223

F

F1-Konverter 171Failover 320Fallback-Codepage 74File-Schnittstellen 149File-Transfer 149, 181Flat Data Type 170, 175Font 320Fool the System 39, 293Frontend 229Frontend-Codepage 29FTP 320

G

GB2312 36Gerätetypen 239German ASCII 320globale Stammdaten 24globaler Zeichensatz 33, 170Globalisierung 13Glyphe 320goldene MDMP-Regeln 47GUI 320GUI_UPLOAD/DOWNLOAD 183

H

halb automatische Übersetzung 272Handshakes 173Hangul 320hexadezimale Kodierung 29Hilfsklassen 151

Hint 88homogene Kommunikation 163, 168HPUTF8 239HTML 320

I

I18N 234I18N-Modus 106I18N-Option 237IDoc 143, 321IDoc-Adapter 168IDoc-Basistyp 196, 202IDoc-Datentransfer

multilingual 206IDoc-Struktur 197, 198, 201, 202, 205,

207sprachabhängig 201, 206

IME 229IMIG 104Import 95Inbound Processing 195, 198, 207, 208INDX-artige Tabellen 72Informationsbeschaffung 246inhomogene Kommunikation 163, 168,

206Input Method Editor 229Interface 321Interface-Katalog 248internationale Adressversionen 285Internationalisierung 13interner Sprachschlüssel 236Internet Transaction Server 55, 321ISCII 321ISO 321ISO 8859 27, 29, 32, 33, 34, 36, 40, 41ISO Latin-1 17ISO/IEC 10646 19ISO-639 228IT-Lösung

globale 289iView 56

J

J2EE 321Java 22, 51Java-Stack 100, 168, 176JDBC 321


330

Index

K

Kanji 321Katakana 321Kodierung

hexadezimal 29Kommunikation

homogene 163, 168inhomogene 163, 168mit RFC 168

Kommunikationsart 178Kommunikations-Codepage 171

Festlegung 173Kommunikations-IDoc 197Kommunikationssprache 193Kommunikationsszenario

Unicode/MDMP 212Kommunikationstechnologie 186Konsistenz-Check 79Konsolidierungsplanungen 259Konvertierung komplexer Landschaften

Kriterien 258Konvertierungsfehler 151Konvertierungsprojekte 244Konvertierungsprozess 164Konvertierungsreihenfolge 246Konvertierungsstrategien 246Konvertierungszeiten 100Kostenabschätzung 253Kryptographie 321KSC5601 36Kundennamensräume 200Kurztext-Editor 273

L

Länder-Customizing 282länderspezifische Informationen 314Landschaft

gemischt 60LANG

Datentyp 176Längenprogrammierung 141Längenzugriff 141Langtexte

multilingual 196Langtext-Editor 273Latin-1-Zeichensatz 32Latin-4 321Laufzeitoptimierung 250

LDAP 51Legacy-Modus 150LEXUTF8 239Little Endian 53, 321Load Balancing 321Locale 41Logon-Sprache 173Lokalisierung 13Lösungsszenarien

Unicode-/MDMP-Kommunikation 194LSB 321

M

Mandantenversorgung 281manuelles Übersetzen 284Markup 321Master-IDoc 197Mastersprache 119MBCS 321MDMP 38, 42, 117MDMP-/MDMP-Kommunikation 172MDMP-Partnersystem 178MDMP-Regeln

goldene 47MDMP-System 42, 46MDSP 42MDSP-System 42Message Broker 321Message Queuing 321Message Type 198, 204, 213Microsoft MS 1250 29, 33Microsoft MS 1251 27Middleware 163, 191, 321Migrationsmonitor 101Mixed-Codepage-System 43MNLS 40MNLS-System 39Modifikation 156Modifikationsgrad 194MSB 321Multi Byte Character Set 321Multi-Byte-Sprachen 35, 206multilinguale ALE-Nachrichtentypen

211multilinguale Langtexte 196multilingualer Datentransfer 176multilingualer IDoc-Datentransfer 206mySAP Business Suite 117mySAP ERP 2004 117


331

Index

mySAP ERP 2005 115, 117mySAP Workplace 55

N

Nachrichtentyp 202Nametab 68Neuinstallation 243NLS_GET_LANGU_CP_TAB 146NNTP 321Non-Unicode-System 136

O

Objektsprachabhängig 268

Objektzeit 15Octet 321ODBC 322Offset-Programmierung 141Offset-Zugriff 141Online-Repository-Texte 273OS 322OS/DB-Migration 63, 255, 289Outbound Processing 195

P

Partnersysteme 165Patch 322Patterns 87PCL 322PC-UI 56Peripherie-Codepages 29PI-Komponente 214Plain Text 322Plug-in-Komponente 214Portal 322PREPARE 120Produktivsystem 317Programme

generierte 157Projektdauer 252Projektlaufzeit 253Proof of Concept 249

Q

qRFC 188, 213

R

R3load 95, 132R3up 123RADCUCNT 68, 122RAID 322RAM 322Referenzsprache 282Release-Wechsel 259Reprocessing 91RFC 322RFC-Adapter 168RFC-Bit-Option 193RFC-Client 173RFC-Funktion 176RFC-Kommunikation 168, 169RFC-Kommunikations-Codepage 196RFC-Konvertierungsverhalten 169RFC-Technologie 168RFC-Unicode-/Non-Unicode-Kommuni-

kation 150RFC-Verbindung 177Rich Text 322RMI 322roundtripfähig 117, 225RSA6 221RSCP_CONVERT_FILE 183RSCPINST 234RSREFILL 281RZ10 155, 236

S

Sandbox-Konvertierung 254SAP .NET Connector 168SAP Country Versions 14SAP ECC 6.0 115SAP Employee Self-Services 117SAP Globalization Services 314SAP GUI 104, 151, 183

Release 6.40 184SAP Java Connector 168SAP Manager Self-Services 117SAP NetWeaver 2004s 115SAP NetWeaver Exchange Infrastruc-

ture 168SAP R/3 Enterprise 117SAP Smart Forms 231SAP Transport Management System 275


332

Index

SAP Web Application Server 135SAP_CODEPAGE 173SAP-Applikationen

Unicode-Fähigkeit 64sapiconv 183SAPinst 132SAP-Logon 105saplpd 239SAPscript 231SAP-Sprachpaket 266SAP-Support-Package 277SAP-Unicode-Workshop 244SAPup 123SAPWIN 239SBCS 322Schnittstellen

Minimierung 259Schnittstellentechnologie 185Schriftzeichen 28, 138

asiatisches 153SCI 159SCOV 158Script 322SE63 233, 237, 273, 274Secure Network Communication 47Service-Oriented Architecture 322Services 244Session Language 173SET LOCALE 182setlocale() 41SGML 322Shift-JIS 322Single Sign-On 47Single-Byte-Codepage 17, 293Single-Codepage-System 17, 27, 32Sizing 322SJIS 36, 41, 322SJIS-Codepage 40SLO 322SM30 237SM59 150, 177SMLT 237, 276, 277, 280SMLT_EX 276SNC 47SOA 322Sonderzeichen 17, 293SPAM 277SPAU 121SPDD 121

spezielle Optionen 177sprachabhängige IDoc-Struktur 201sprachabhängige IDoc-Transferstruktur

206sprachabhängige Tabelle 175sprachabhängiges Customizing 279sprachabhängiges Objekt 268Sprachauffüllung 233Sprachbestimmung

Methoden 86Sprachen 16

Kombination 37Sprachen-CD 277Sprachenvektor 236Sprachimport 268, 277, 279Sprachinstallation 268Sprachschlüssel 45, 228

interner 236Sprachtransport 275SPRAS 46SPUM4 120, 261SPUMG 71, 120SQL 322SSO 47Stammdaten

globale 24Statistik 273Step-Sprache 223Strukturen 139

flache 139geschachtelte 139nicht geschachtelte 139tiefe 139zeichenartige 139

SUMG 71, 128Support-Package 65, 211, 277Surrogate-Bereich 52SY-LANGU 182synchrone Übertragung 322System-Codepage 29, 36, 182Systemkonsolidierung 263Systemlandschaft

Vereinfachung 263Systemvokabular 72, 81Systemzeit 15

T

Tabellenstrukturen 175


333

Index

TABLES 176Table-Split 102Tastaturlayout 231TCP/IP 323TCP0C 172, 173TECHED_UNICODE_EXERCISE 157TECHED_UNICODE_SOLUTION 157Textsprache

DDIC-Attribut 74Textsprache-Flag 176TIS620 36TOOLIMP4_UCMIG 124Transferstruktur 188Transport

Unicode/Non-Unicode 112tRFC 195, 197tRFC-Verbindung 207TU & UC 116, 262Twin-System 262

U

Übersetzunghalb automatisch 272manuell 284von Geschäftsdaten 266

Übersetzungslücken 279Übersetzungsstrategie 231, 233Übersetzungstransporte 275Übersetzungswerkzeuge 272Übersetzungs-Workbench 69, 273Übertragung

asynchron 319synchron 322

UCCHECK 121, 154, 249UCMIG_REQINC 125UCMIG_STATUS_CHK1 126UCS 323UM4_TXFLAG_UPLOAD 126Unambiguous-Blended-Codepage 41Unicode

SAP-Hinweise 315Unicode Consortium 22, 314Unicode Enabling 248Unicode Encoding Forms 20, 323Unicode Encoding Schemes 20, 323Unicode Transformation Format 20, 54,

323

Unicode-/MDMP-KommunikationLösungsszenarien 194

Unicode-/MDMP-Kommunikationsszena-rio 212

Unicode-Architektur 59Unicode-Codepage 19Unicode-Codepoint 29Unicode-Drucker 112, 232, 238Unicode-Fähigkeit

SAP-Applikationen 64Unicode-Flag 136Unicode-Font 239Unicode-Kodierungsschema 52, 62Unicode-Konvertierung 63, 289, 317,

318Dokumente 317Gründe 252Hardware-Bedarf 66typischer Ablauf 317

Unicode-Nametabs 120Unicode-Neuinstallation 243Unicode-Norm 22Unicode-Projekt 314Unicode-Skalarwert 29unicodespezifische Anleitungen 314Unicode-Standard 19Unicode-Strategie 245Unicode-System 136

Sprachen 299Unicode-Versionen 23Upgrade 211User-Exit 156, 215UTF 323UTF-16 21, 53, 164UTF-8 20, 53, 164

XML-Zwischenformat 171UUEncode 323

V

VAS 232vietnamesischer Zeichensatz 232Voice over IP 323Vokabularpflege

Varianten 90Vokabulartransfer 85Vorschlagspool 272, 273


334

Index

W

W3C 323Währungen 15Wartungslandschaft 255WE8DEC 29WML 51, 323Wrapper-Funktion 202WS_DOWNLOAD 151WS_UPLOAD 151WSDL 323

X

XBRL 323XHTML 323

XML 51, 323XRFC 170

Z

zcsa/installed_languages 236Zeichen 28zeichenbasierte Datentypen 171Zeichenelemente 28Zeichensatz 28

ASCII 170globaler 33vietnamesisch 232

Zeitzonen 15Ziel-Codepage 171Zwei-Server-Methode 101


Documents

832.book Seite 3 Montag, 9. Oktober 2006 12:57 12