unicode in sap systems - edv-buchversand

Bonn � Boston

Nils Bürckel, Alexander Davidenkoff, Detlef Werner

Unicode in SAP® Systems

135.book Seite 3 Montag, 2. April 2007 11:39 11

Contents at a Glance

1 Introduction ............................................................ 13

2 Language Support in SAP Systems ......................... 27

3 Implementing Unicode in SAP Applications ........... 57

4 Guidelines for Unicode Projects ............................. 233

5 Languages and Translation ..................................... 253

6 Summary ................................................................. 275

A Code Page Tables .................................................... 279

B Languages in an SAP Unicode System .................... 287

C Literature References and Other Support .............. 299

D Glossary .................................................................. 305

E The Authors ............................................................. 311


7

Contents

Preface ........................................................................................ 11

1 Introduction ............................................................. 13

1.1 Globalization and Localization .................................... 131.2 Language Support in IT Systems .................................. 161.3 Unicode ...................................................................... 19

1.3.1 Character Encoding ........................................ 201.3.2 Java and Unicode ........................................... 211.3.3 Unicode Development ................................... 221.3.4 Modern Business Processes and

New Markets ................................................. 231.4 Summary .................................................................... 25

2 Language Support in SAP Systems .......................... 27

2.1 From Single Code Page Systems to Unicode ................ 272.1.1 Characters, Character Sets, and Code Pages ... 282.1.2 Historical Development of Language

Processing at SAP ........................................... 292.1.3 Single Code Page Systems .............................. 32

2.2 Combination of Languages in a System ....................... 362.2.1 “Fool the System” .......................................... 382.2.2 MNLS System ................................................ 382.2.3 Blended Code Page System ............................ 392.2.4 MDSP System ................................................ 402.2.5 MDMP System ............................................... 41

2.3 Unicode in the SAP System ......................................... 482.3.1 Multilingual Data Exchange ........................... 482.3.2 Unicode Basics ............................................... 492.3.3 Unicode Formats in SAP Systems ................... 51

2.4 Transition to SAP NetWeaver and Enterprise SOA with Unicode .............................................................. 52

2.5 Summary .................................................................... 55

3 Implementing Unicode in SAP Applications ............ 57

3.1 Unicode Architecture .................................................. 573.2 Unicode Conversion ................................................... 60


Contents

8

3.2.1 Generally Necessary Conversion Steps in a System .................................................... 61

3.2.2 MDMP and Blended Code Page-Specific Steps 673.2.3 Export and Import ......................................... 953.2.4 SAP GUI for Windows ................................... 1003.2.5 Printing in the Unicode System ...................... 1063.2.6 Transport between non-Unicode and

Unicode Systems ........................................... 1073.2.7 Conversion of SAP NetWeaver BI and

SAP CRM Systems ......................................... 1083.2.8 Summary ....................................................... 109

3.3 Upgrades and Unicode Conversion ............................. 1093.3.1 Sequential (Separate) Upgrade and Unicode

Conversion .................................................... 1133.3.2 Combined Upgrade and Unicode

Conversion .................................................... 1133.3.3 Twin Upgrade and Unicode Conversion ......... 1233.3.4 Comparison of the Combined Procedures ...... 126

3.4 ABAP and Unicode .................................................... 1283.4.1 Overview ...................................................... 1293.4.2 Unicode-Relevant Changes and Additions

in ABAP as of SAP Web AS 6.10/6.20 ........... 1313.4.3 Tools for Unicode Enabling ............................ 1473.4.4 Summary ....................................................... 154

3.5 Communication and Interfaces ................................... 1543.5.1 Homogeneous and Inhomogeneous

Communication ............................................. 1563.5.2 Communication with RFC .............................. 1603.5.3 Communication Using File Transfer ............... 1733.5.4 Communication Between SAP Unicode

and SAP non-Unicode MDMP Systems .......... 1783.6 Expansion into New Countries with Unicode .............. 217

3.6.1 Technical Configuration of a New Language in SAP Unicode ............................................. 218

3.6.2 Case Study: Introduction of Vietnamese in an SAP Unicode System ............................. 221

3.7 Summary ................................................................... 228

4 Guidelines for Unicode Projects ............................... 233

4.1 New Installation ........................................................ 2334.2 Unicode Conversion ................................................... 234


Contents

9

4.2.1 Typical Steps in a Conversion Project for an Environment with Three Systems ................... 234

4.2.2 Determining Factors of a Conversion Project .. 2414.2.3 Comparison with Upgrade Projects and

OS/DB Migration ........................................... 2444.2.4 Converting Complex Landscapes .................... 247

4.3 Release Changes and Unicode Conversion .................. 2484.4 System Consolidation ................................................. 2514.5 Summary .................................................................... 252

5 Languages and Translation ...................................... 253

5.1 Language and Translation Management ...................... 2545.1.1 Translation Objects ........................................ 2555.1.2 Language Installation ..................................... 256

5.2 Customer-Specific Translations ................................... 2575.2.1 Translation Strategies ..................................... 2575.2.2 SAP Translation Tools ..................................... 2595.2.3 SAP Translation Workbench ........................... 2615.2.4 Language Transport ........................................ 2625.2.5 Language-Dependent Customizing ................. 2665.2.6 Address Versions ............................................ 271

5.3 Summary .................................................................... 273

6 Summary ................................................................... 275

Appendix ........................................................................ 277

A Code Page Tables .................................................................. 279B Languages in an SAP Unicode System .................................... 287C Literature References and Other Support .............................. 299

C.1 Literature ................................................................... 299C.2 Links ........................................................................... 300C.3 SAP Notes .................................................................. 301C.4 Documents Needed for Unicode Conversions ............. 303C.5 Typical Process of Testing a Unicode Conversion ........ 303

D Glossary ................................................................................ 305E The Authors .......................................................................... 311

Index ............................................................................................ 313


11

Preface

The only constant is change. Not only are there a daunting numberof languages, divided into language families, but every languageinevitably changes over even a relatively short time. Continuouscommunication is the reason.

A significant challenge during the fast-paced development of infor-mation technology and computers was therefore the attempt toencode language and the characters associated with it into a formsuitable for machines, so as to be able to store and exchange data.Data exchange was, and still is, particularly challenging, since onemust define certain standards in order to ensure the smoothest pos-sible data exchange between different computers and programs.Over time, it became clear that the variety of different formats intro-duced—particularly with increasing globalization—were still unableto represent languages sufficiently well, and that there were evenerrors during data exchange between heterogeneous IT platforms.

The solution to this omnipresent problem was the introduction ofUnicode. For the first time, a globally accepted, uniform standardhad been created that, thanks to the fixed assignment of one numberto every character, guarantees that texts in any language can be dis-played and transmitted without error, both today and in the future.

Contents“When the world wants to talk, it speaks Unicode.”1 Besides the basicprinciples of Unicode, this book also describes how Unicode is sup-ported by SAP as the future technological basis for all its softwareproducts. This book is intended for a broad audience: from the topmanager or CIO who needs to decide how the enterprise's ERP sys-tem can best be converted to use Unicode, to the project managerwho introduces new Unicode-based software, to the IT specialistwho needs to know the steps to make in-house software Unicode-capable or how an existing ERP system can be converted.

1 This was the motto of the 20th International Unicode Conference in 2002.


12

Structure After a general introduction in Chapter 1, you will read in Chapter 2how languages are generally supported in SAP systems. Chapter 3then covers Unicode-based installations and shows how existingsolutions can be converted. It first describes the basic architecture ofan SAP Unicode system (Section 3.1). Based on that foundation,there is a detailed description of a Unicode conversion of an MDMPsystem (Section 3.2). In Section 3.3, we will discuss combining anupgrade with a Unicode conversion. ABAP enabling and the han-dling of interfaces form a very large part of a Unicode conversion, soSections 3.4 and 3.5 are devoted to these topics separately. To con-clude the chapter, we will describe the options for expansion intocountries for which Unicode is a requirement (see Section 3.6). Howyou can effectively manage these projects is the topic of Chapter 4,after which Chapter 5 discusses the topic of translation. Chapter 6summarizes the key points of the first five chapters with respect toUnicode installation and conversion.

The book is structured so that you can read selected chapters or sec-tions independently. For instance, a programmer with basic Unicodeknowledge could simply read the information in Section 3.4 regard-ing “ABAP and Unicode” to discover how programs can be verifiedfor execution in a Unicode system and, if necessary, how they mustbe changed.

In all explanations, great value is placed on specific practical exam-ples that we, the team of authors (from SAP Globalization Services),can guarantee. We all have years of experience with the introductionof Unicode into SAP software, whether in internal SAP projects likethe Unicode Enabling of SAP R/3 Enterprise or the global support ofSAP customers, as with Unicode conversions.

Acknowledge-ments

The authors would like to take this opportunity to thank all the SAPcustomers, partners, and colleagues who helped with the creation ofthis book, particularly for all the valuable discussions. Our particularthanks go to the management of SAP Globalization Services for theopportunity to write this book.

Nils Bürckel, Dr. Alexander Davidenkoff, Dr. Detlef WernerWalldorf, St. Leon-Rot, February 2007


233

All SAP applications are available based on Unicode. In this chapter, you will learn how you can optimally plan and exe-cute a new installation or the conversion of an existing sys-tem.

4 Guidelines for Unicode Projects

Today, all SAP applications are available in Unicode-based versions,and new software products from SAP such as the SAP NetWeaverExchange Infrastructure (SAP XI) or the SAP NetWeaver Portal arenow only delivered as Unicode versions. The support for obsoletesolutions for the combination of languages and code pages—such asMDMP in SAP R/3—is being terminated step by step, so that SAPERP 2005 no longer supports MDMP. As of 2007, all new installa-tions of applications based on SAP NetWeaver will only be possibleunder Unicode.

4.1 New Installation

New installation has not changed

The new installation of a Unicode-based system is basically no differ-ent from that of a non-Unicode installation. However, the followingshould be taken into consideration in the implementation project:

� As mentioned in Chapter 3, a Unicode system has somewhathigher hardware requirements; these must be taken into account.

� If there are interfaces to non-Unicode systems, the configurationmust be undertaken with care, in order to eliminate such risks asdata loss because of incorrect conversion.

� The same applies for uploads or downloads of files which come tothe system over the network (by means of FTP, for example).

� If third-party software will be integrated, you must carefully checkthat it will function smoothly with the SAP Unicode installation. Arequest to the appropriate SAP software partner will usually suf-fice.


234

Guidelines for Unicode Projects4

� When creating custom developments, you should proceed in com-pliance with Unicode, as described in the SAP Unicode EnablingCookbook (see Appendix C) and in Section 3.4.

Workshops bySAP Globalization

Services

4.2 Unicode Conversion

4.2.1 Typical Steps in a Conversion Project for an Environment with Three Systems

You can see a rough overview of the conversion of one SAP system inFigure 4.1, which shows the typical phases of a conversion. The planfor a conversion is always the same: Preparation takes on a veryimportant role, followed by the conversion itself, and then the phaseof postprocessing.

Figure 4.1 Overview of the Steps Necessary for the Conversion of an SAP System

In the following sections, we will describe in more detail how a Uni-code conversion project for a three-system environment might bestructured. In the evaluation phase, we work out the consequencesUnicode will have for the existing system environment and whichUnicode strategy is to be followed. The actual preparation phase fora particular system environment follows. Then, a sandbox conver-

Tip

SAP Globalization Services offers different services and workshops thatexplore individual Unicode aspects in detail according to customerrequirements, either before or during a project. The SAP Unicode Work-shop is the ideal introduction for all Unicode projects. You can find a list ofall services at SAP Service Marketplace (http://service.sap.com/globaliza-tion) in the Service Offerings area.

Preparation ConversionPostprocessing

- Conversion Project

- Prerequisites

- MDMP Preparation(SPUMG)

- Enabling of Customer-Specific Objects(UCCHECK)

- Export and Import Processes

- Downtime

- Performance Optimizationin the Case of LargeDatabases

- Unicode System getsStarted

- Verification of Data

- Integration Tests with Focus on LanguageHandling


235

Unicode Conversion 4.2

sion is carried out as the first test environment. The sandbox conver-sion may need to be repeated several times. In parallel with this, thedevelopment system (DEV) or the consolidation system (QAS) canalready be converted. After all the tests in QAS and in the sandboxsystem have been completed successfully, the conversion of the pro-duction system (PRD) follows.

The steps presented here must be adapted to the actual customer sit-uation. This list also makes no claim to completeness.

Project Evaluation Phase

Before any Unicode conversion project, we must clarify what Uni-code means in the specific situation of the client. In general, cost andeffort are the focus. However, we also should consider what effortswill be caused and what consequences will result if Unicode is notintroduced. It is often necessary to have a “business case” to justifyextensive investments in new technology.

At the end of this phase, the general Unicode strategy of the com-pany regarding SAP technology should be clear. However, the strat-egy may still need to be adapted as conditions change, so its validitymust be verified at regular intervals.

The following points describe possible factors to be taken intoaccount in this step:

� Unicode conversion process and consequencesWhat has to be done during a Uni-code conversion?

In this phase, it is important to understand the principle of Uni-code conversion. What steps and effort are necessary, and wheremust the customer make adaptations?

� Acquiring relevant customer-specific informationInformation acquisition

To be able to produce a reasonable Unicode strategy, the informa-tion on Unicode available from SAP must be complemented withthe customer's own data. The following list includes the mostimportant points:

� Overview of the system landscape (systems, releases, supportpackages, front-end software, and so on)

� Database sizes (in GB), the 50 largest tables, and the hardwareconfiguration of all relevant systems


236


� Requirements pertaining to tolerable downtime for individualsystems

� Code page setup of all systems (Unicode, MDMP, single codepage, blended code page)

� Description of the interfaces between the systems and to non-SAP systems (“rough interface catalog”)

� Existing add-on solutions (SAP and non-SAP)

� Number and type of existing custom developments

� Existing rollout plans in other countries for the different sys-tems

� Planned system mergers

� Possible conversion strategies

Attention to these points generally results in the conversionsequence for the existing systems. For the systems to be con-verted, the first option at this point is to discuss the procedures forconversion strategies (for instance, the creation of a sandbox sys-tem) and also ways to minimize downtime (see Chapter 3).

Conversionstrategies

� Evaluation of the consequences should Unicode conversion bepostponedCustomers should consider carefully what the postponement ofUnicode means from short-term and long-term perspectives. SAPNote 79991 regarding the SAP support for non-Unicode should beconsidered carefully in this context (see Table 2.7 in Chapter 2).

� Experience of other customersAn exchange of experiences with other customers at the start ofthe project and also over the course of the project promotes betterunderstanding of possible problems and workarounds.

� First “rough” estimate of effortA first approximate estimate of effort should consider the pointsof hardware requirements, resource requirements, and projectduration.

� Business case and creation of initial project planThe analysis above allows a preliminary project plan to be created.This plan generally doesn't include any exact details of the conver-sion.


237


Project Preparation Phase

In the preparation phase of the project, we begin the system-specificpreparations for the coming Unicode conversion. Conditions andlimitations must be checked and patches may need to be installed.The necessary hardware must be procured. All available documentson Unicode conversion should also be studied. It is recommended tocreate a detailed project plan for the coming sandbox conversion.The following points should be taken into consideration:

� Detailed prerequisites and restrictionsPreparatory stepsIf products from other manufacturers are used in the SAP environ-

ment, we recommend that the Unicode capability of these solu-tions should be certified by the manufacturers. In general, youcan't assume that an SAP certification also means Unicode capabil-ity.

For relatively “old” patch levels in SAP solutions, there is a highprobability that an update will be necessary. For extensivechanges (SAP GUI for Windows, for example), the tests shouldfirst be performed with the current patch level before a global roll-out is started.

� Interface catalog with language dependenciesA list of all interfaces and their language dependencies (e. g., “aretests with special characters transmitted?”) helps identify criticalareas.

� Hardware procurementFor larger systems, a sandbox conversion is absolutely recom-mended. The temporary hardware needed for this must be pro-vided. If the hardware is to be updated during the production con-version, this must be planned in advance.

� Options for performance optimizationTo prepare a sandbox conversion, we should have examined whatmeans are available for runtime optimization and what will makesense for the initial conversion. It may well be that certain meth-ods are not yet fully available. In that case, additional steps may benecessary.

� Determination of the strategy for handling ABAP objects(UCCHECK)In this example, we will assume that the ABAP objects are alreadyadapted in advance (see the subsequent bullet point on ABAP).


238


Archiving beforeUnicode

conversion

� Use of all possible archiving options to reduce database sizeBy reducing the size of the database, it is possible to improve sev-eral aspects of the conversion. These include the export andimport times for the production conversion. The runtime ofTransaction SPUMG will be shorter if there is less data to scan.

� Necessary documentation and SAP NotesAll necessary guidelines and associated SAP Notes should bedownloaded. During the course of the project, we recommendthat you check regularly whether there are changes to the SAPNotes or in the conversion guidelines.

� Enabling of ABAP objects (Unicode enabling)The handling of ABAP objects is fully possible only as of BasisRelease 6.10 using Transaction UCCHECK. If the release is 6.10 orhigher, the objects can be adapted in advance. The objects arethen ideally executable either under under Unicode or in a non-Unicode environment. Since the result is a certain independencefrom the Unicode conversion, the UCCHECK processing is per-formed as a separate task. For new developments (creation of newABAP objects) the Unicode flag is set by default as of SAP Web AS6.10, so that in this case Unicode capability is largely assured.Existing objects without the Unicode flag that must be adaptedduring ongoing maintenance should also be made Unicode-capa-ble now, because these objects then must only be tested once.

Structure and Conversion of the Sandbox System

“Proof of concept” Once the prerequisites for the sandbox conversion have been ful-filled, you can carry out the first test conversion. Care should betaken that even during the first attempt the known performanceoptimizations are used during export and import. The following listprovides an overview of the steps:

Steps for sandboxconversion

� Structure of the sandbox system as a copy of PRDIn the ideal case, the hardware of the sandbox system already cor-responds roughly to the hardware of the PRD system for this ini-tial test. In that case, the results of the scan times and theexport/import times can be accurately used in estimating thebehavior of the production system.

In practice, however, there is usually no comparable hardwareavailable, so that at first the process of conversion itself is being


239


tested with no real focus on the runtimes. For large systems, how-ever, this can result in very long runtimes, so that the entire testtakes a very long time.

� Preparatory steps for Unicode conversionThe main area for preparation for Unicode conversion of anMDMP system is Transaction SPUMG. Sufficient time must bebudgeted for the scans which build the system vocabulary, forprocessing of the vocabulary, and also for the reprocessing scans.The runtimes of the scans for large systems run in the range froma few days to several weeks. The scan without language codes gen-erally requires the longest time, but the reprocessing scan can alsorequire a large percentage of the project time.

Time also is needed for assignment of the vocabulary entries.Because the system vocabulary maintained in the sandbox systemforms the basis for the later conversion of all existing systems, thisprocess should be executed immediately at the outset with all nec-essary care.

� Export and importThis area includes the tests relevant to runtime optimization. IfTransaction SPUMG has already been sufficiently well tested, it isnot necessary to execute this transaction repeatedly as a prepara-tion scan. This would take—in the worst case—several weeks eachtime. Alternatively, a backup after completion of the SPUMGwork can be used as a starting system.

� Execution of post-conversion tasksTransaction SUMG covers the most important reprocessing steps.This transaction can be used to estimate the effort for manualrepair. Repair hints may already be generated here.

� Test phaseAfter the Unicode conversion is complete, tests of the applicationsfollow. For instance, a part of the custom ABAP objects can betested. If possible, interface tests should also be performed at thispoint. Normally, however, this is only fully possible in the QAS,because in the sandbox system the interfaces must first be set up.

However, it is always the case that all tests that can already be per-formed in the sandbox system should be performed there. Theearlier a problem is discovered, the more time you will have tocorrect it.


240


� Analysis and results of the sandbox conversionThe sandbox conversion provides results for the R3load runtimeoptimization, the procedure, and the scan runtime for Transac-tions SPUMG and SUMG, as well as for initial Unicode testingafter the conversion phase. Based on these results, you now mustdecide whether additional sandbox conversion runs are neededand when the next systems in the landscape should be converted.There follows a corresponding refinement and adaptation of theproject plan to the continuing procedure.

� Repetition of the sandbox conversion (depending on the resultsof the previous conversion)The sandbox conversion should be repeated until the require-ments for downtime are met. In parallel with this, the conversionof the QAS or the DEV system can be started.

Converting the Development or the Quality Assurance System

The conversion of the DEV or the QAS system is performed analo-gously to conversion the sandbox system. Under some circum-stances, it may be possible to accept longer downtimes here thanwith the production system.

Meaningful interface and integration tests are generally only possi-ble on the quality assurance system. A parallel preliminary test ofTransaction SPUMG on the PRD system at this point will ensure thatthe scan duration of this transaction is not underestimated.

Converting the Production System

Factors influenc-ing the effortof a Unicode

conversion

Based on the experience with the sandbox system as well as the DEVand QAS systems, the conversion of the production system can nowproceed. It is important that the conversion is performed underexactly the same conditions as those pertaining to the test system.For instance, the patch level of the kernel (particularly the R3loadversion) should be identical to that of the other systems.

The first day or the first week after the conversion generally requiresparticular attention, since there may be problems in some areas. Youshould take this into consideration in your planning.


241


4.2.2 Determining Factors of a Conversion Project

Possible reasons for a Unicode conversion

At the outset of a Unicode project, there is a typical series of ques-tions, which will be clarified in this section. The following list showsinitial possible reasons for a Unicode conversion:

� The organization desires an upgrade of the existing MDMP systemto SAP ERP 2005 (see SAP Note 79991).

� English should be possible as the central logon language for allcountries or languages.

� The data exchange between MDMP and Unicode causes problems.

� Java technologies (such as ESS/MSS on SAP ERP 2004) should beused in the MDMP environment.

� Rollout is needed in other countries that are not covered by theexisting non-Unicode solution in the system.

� The organization needs to consolidate systems with differentcode-page configurations.

� The organization anticipates rollout in countries whose charactersare not supported except in Unicode (for example, Arabic or Viet-namese).

� Support of dialects (such as Canadian French) is needed.

� The organization needs to display certain characters (e. g., the €character) that are not supported except in Unicode.

� Internet connection (e. g., a Web store) is needed.

� Strong Java integration of the system is needed.

Duration of a con-version project

The project duration for a Unicode conversion, like that for anupgrade, is determined by many factors. The main areas are shownin Table 4.1. In addition, the duration depends on the number ofresources available and their state of knowledge.

Factors

Effort

Easy Medium Difficult

Language tech-nology used

Single code page Asian code page MDMP

SAP solution used SAP Web AS (standalone)

SAP ERP or SAP R/3 Enterprise

SAP CRM with Mobile Sales

Table 4.1 Effort Involved in a Unicode Conversion


242


As a minimum value for the conversion of a three-system landscape,you can assume about four weeks of project runtime. On average,these projects take about three to four months. For very large MDMPsystems with very many custom ABAP objects or interfaces to otherMDMP systems, the runtime can even be more than a year.

Costs of a Unicodeconversion

A cost estimate, too, depends on the factors listed in Table 4.1. More-over, in this area the additional hardware requirements must betaken into account. Expenses for testing and for the adaptation ofcustom reports may under some circumstances represent a large partof the overall budget.

Specialists needed A Unicode project also requires expertise in the area of ABAPenabling as well as in the interface area. Specialists in the program-ming environment and employees with SAP NetWeaver knowledgewill be needed. Transaction SPUMG is generally executed by SAPNetWeaver experts. For the preparation of the system vocabulary,however, people will also be needed who know each language. Theexport and import procedures and optimization are comparable toan upgrade and also require technical knowledge. Testing is gener-ally the responsibility of the application.

Database size Database < 300 GB

Database between 300 GB and 1,500 GB

Database > 1,500 GB

Downtime accepted

Downtime > 4 days

Downtime from 2 to 4 days

Downtime < 2 days

Hardware properties

Very fast hardware Medium hardware

Slow hardware

ABAP objects enabling

Small number of objects

Medium num-ber of objects

Large number of objects

Conversion method

Standard Split of large tables

IMIG/CU & UC

SAP interfaces Unicode systems Single code page systems

MDMP systems

Non-SAP interfaces

Unicode systems Single code page Latin-1

Asian code page

Factors

Effort

Easy Medium Difficult

Table 4.1 Effort Involved in a Unicode Conversion (cont.)


243


Conversion vari-ants in a three-system landscape

Figure 4.2 shows two possible scenarios for a Unicode conversion:On the left is a conversion with a sandbox, and on the right you seea scenario without a sandbox, where the QAS is converted before thedevelopment system.

Figure 4.2 Possible Conversion Scenarios for a Three-System Landscape

Sandbox conversion

The conversion using a sandbox is the procedure recommended bySAP for a Unicode conversion. However, this still doesn't answer thequestion of when a sandbox conversion is absolutely necessary. Inthe following cases, a sandbox conversion is difficult to avoid:

� Critical requirements for downtime or conversion of very largesystemsConversion runtimes can only be meaningfully tested on sandboxsystems with comparable hardware parameters. Extrapolation ofruntimes from very weak servers to production environments isextremely uncertain. As a result, the probability of surprises dur-ing the production conversion increases if sufficient testing doesnot take place under comparable conditions.

D Q P

S

D Q P

D Q P

S

D Q P

D Q P

D

D Q P

D Q P

StructureSandbox

ConversionSandbox (n times)

ConversionDevelopment

ConversionQAS

D Q P

ConversionPRD

Conversion with Sandbox Conversion without Sandbox

ConversionQAS

ConversionDEV

ConversionPRD

D Q P

X Non - Unicode

X Unicode

D DEV

Q QAS

P PRD

S SBX

Q P


244


� MDMP conversionIn the case of an MDMP conversion, SAP strongly recommends atest conversion of a copy of the production system. This is theonly way to completely test the conversion.

� Combined upgrade and conversion solutionsThe basic prerequisite for more complex solutions like CU & UC(see Section 3.3) is the construction of separate test systems. In thecase of TU & UC, a twin system must be built anyway.

� QAS conversion before DEV conversionIt is worth considering whether the QAS should be convertedbefore the development system. A “proper” test of the interfaces isoften only possible on the QAS. Problems with interfaces, how-ever, should be identified quickly, given that correction may bedifficult under some circumstances. In principle, the same thingapplies for a meaningful integration test.

� Conversion with “Maintenance landscape”Analogous to upgrades, there is a scenario of non-Unicode main-tenance systems (DEV and QAS) which will support the non-Uni-code production system during the Unicode conversion. Thisensures that a critical problem that occurs differently in a non-Unicode environment than with Unicode can be correctedquickly.

4.2.3 Comparison with Upgrade Projects and OS/DB Migration

On the topic of upgrades, there is a great deal of documentation, andmost customers already have been through at least one upgradeproject. Some customers also have experience in the area of OS/DBmigration. With this type of background, the following comparisonof a Unicode conversion with an upgrade and OS/DB migration canbe quite helpful:

Functional changesin a Unicode con-

version and anupgrade

� FunctionalityDuring an upgrade, applications may change thoroughly, so thatexisting custom development may need to be adapted. In a Uni-code conversion or OS/DB migration, the application end of thesystem changes only minimally.


245


� System DowntimeComparison of downtime between a Unicode conversion and an upgrade

The dependency of downtime for the conversion of the produc-tion system on the database size is significantly larger for a Uni-code conversion. In an upgrade, this dependency is generallycompensated for by hardware, which tends to be better on alarger system. This trend can also be seen in Unicode conversions,but corresponding efforts must be made to optimize performance.

The downtime in a Unicode conversion is comparable to thedowntime in an OS/DB migration. However, the CPU require-ments for a Unicode conversion are significantly higher, becausethe compressed cluster tables, for instance, must be subjected tomany computationally intensive operations (the data is decom-pressed, converted, and then recompressed).

� Comparison with UCCHECK and SPUMG EnablingUnicode enabling needed

The adaptations in the area of custom development (throughTransactions SPAU or SPDD) can best be compared to theUCCHECK enabling; however Transaction UCCHECK showsdirectly where objects must be changed. Moreover, the objectscan be adapted in the non-Unicode system, even before Unicodeconversion. This generally doesn't apply for an upgrade. For anMDMP system, Transaction SPUMG corresponds to no particularstep in an upgrade. A scan of the entire database and the associ-ated maintenance of the results are not necessary for an upgrade.

Adaptations in the interfaces for a Unicode conversion, particu-larly for an MDMP system, require particular attention (see Chap-ter 3). In the case of an OS/DB migration, adaptations must bemade to custom ABAP objects which contain database-specificcommands (e. g., Native SQL).

� Release LimitationsRelease limita-tions for a Uni-code conversion

In an upgrade, the release of the SAP system changes after the pro-cess is finished. Generally, an upgrade is possible in the sourcesystem for most of the releases still supported.

A Unicode conversion, on the other hand, is executed by defaulton a single release. There are limitations, both on the Unicode side(R/3 releases up to 4.6C don't support Unicode) and on the non-Unicode side (MDMP or blended code pages are no longer sup-ported as of SAP ERP 2005).


246


In an OS/DB migration, there are only a very few release limita-tions. Generally, a migration can be performed on any supportedrelease. Just as for a Unicode conversion, the release does notchange during a migration.

When is adevelopment

freeze necessary?

� Development Freeze During the ProjectIn an upgrade, transportation between the different releases is notsupported. That means that a development freeze during theupgrade project can hardly be avoided.

In the case of a Unicode conversion, it is quite possible to performa transport between Unicode and non-Unicode releases (with lim-itations where MDMP is concerned). That means that a develop-ment freeze may not be absolutely necessary. SAP’s recommenda-tion, however, is to minimize the number of projects as far as pos-sible during the Unicode conversion, as there may very well bedifferences between Unicode and non-Unicode systems (forinstance, where interfaces are concerned).

How often must aUnicode conver-

sion be performed?

� FrequencyA Unicode conversion must be performed exactly once per sys-tem. After that, no more projects are necessary. An upgrade, onthe other hand, must generally be performed on a regular basis.An OS/DB migration lies somewhere in between. For most cus-tomers it is a rather unusual task and is not repeated often for eachsystem.

What needsto be considered

in terms ofuser training?

� End User TrainingFor an upgrade, end users must often be trained, since the func-tionality may have changed.

For a Unicode conversion, there are only a very few areas wherethe users even notice that there has been a technical change.Examples are the Word editor for SAPscript editing and uploadsand downloads, where a target code page may need to be givenunder some circumstances. If the Unicode conversion is combinedwith an upgrade, however, there must be corresponding trainingfor the end users.


247


4.2.4 Converting Complex Landscapes

In what order should SAP sys-tems in complex landscapes be converted?

Besides an ERP application, many customers use a number of otherSAP applications. These are generally connected, and the questionimmediately arises as to the order in which the different systemsshould be converted.

It is generally impossible to convert all systems in one weekend,because there would be an extremely great effort associated withthat. But the risk that the entire conversion fails on one weekend isalso very high for such a “big bang” conversion.” If you assume thatfive closely connected production systems are to be converted in asingle weekend, then no system can be allowed to have a significantprogram that cannot be corrected immediately, because otherwise allthe systems will need to be reset.

Criteria for conver-sion of complex landscapes

Based on the following criteria, a customer-specific evaluationshould be made as to the optimum order:

� Unicode capability of the different SAP applications (releases)The prerequisite for Unicode conversion is the Unicode capabilityof the release. For instance, if a system is running on SAP R/34.6C, the conversion can only take place after an upgrade.

� Requirements pertaining to languages and countries in the dif-ferent systemsSystems that must handle data from multiple “old code pages”should be higher-priority candidates for Unicode conversion. Sys-tems without corresponding requirements (purely single code-page systems) can be converted at a later date.

� Minimization of interfaces between MDMP and Unicode systemsThe interface problems described in Section 3.5 between Unicodeand MDMP systems leads to the very important criterion that thenumber of MDMP systems in the system environment should bekept as low as possible.

� Upgrade planning for MDMP systems based on SAP NetWeaver2004sAs of SAP NetWeaver 2004s, MDMP is no longer supported (seeSAP Note 79991). Thus, for upgrade planning for correspondingsolutions, Unicode conversion should be planned as well.


248


� Consolidation plansFor planned consolidations, particularly when different codepages are in use, a conversion to Unicode is a good alternative.

� Database sizes of different systems and quickly growing data-basesThe effort of a Unicode conversion depends strongly on the size ofthe database. If there are systems in the environment that have ahigh rate of growth, then you should consider converting that sys-tem earlier rather than later.

� Planned projects and regular actionsUnicode conversion should ideally happen in a “project-sparse”time. Ideally, existing projects should be postponed until after theconversion. But critical projects like annual reporting must also betaken into account. Unicode conversion shortly before annualreporting is generally problematic.

4.3 Release Changes and Unicode Conversion

How can anupgrade and Uni-

code conversion becombined?

Upgrades (release change) and Unicode conversions are bothprojects in the course of which a great deal of application testing isnecessary. Although these are two logically independent steps (seeFigure 3.3 in Chapter 3) there is still the question of how well thetwo tasks can be combined.

In Section 3.3, appropriate combined procedures were alreadydescribed. These are particularly interesting in relation to an upgradefrom a non-Unicode-capable release with MDMP to SAP ERP 2005,because in that target release MDMP is no longer supported (see SAPNote 79991).

In summary, these are the possibilities for integration tasks into anupgrade:

Greatest possiblelogical separation

of upgrade andUnicode

conversion

� Separate projectsThe upgrade is executed completely separately from Unicode con-version.

� Consideration of ABAP objects during the upgradeThe enabling of ABAP objects to the stricter Unicode syntax rulesis considered during the upgrade. Separate integration tests forthe changes to ABAP objects in non-Unicode are not necessary.


249

Release Changes and Unicode Conversion 4.3

� Upgrade and Unicode conversion in one project, but on separateweekends

Advantages and disadvantages of the combination of upgrade and Uni-code conversion into one project

It is possible to perform the conversion and the upgrade in oneproject, but to select a different weekend for the conversion of theproduction system. Assuming that the upgrade is performedbefore the conversion, this means that tests must be performedboth in the non-Unicode and the Unicode systems, as in this casethe non-Unicode system will be going live on the new release.

The advantages of this approach would be that a sandbox systemcould be used both for the upgrade and for the conversion, andthat tests may be performed twice, but otherwise would still beperformed shortly after one another in an identical procedure.

� Upgrade and Unicode conversion on the same weekendThe main criterion for the decision whether the conversion andthe upgrade can be performed on one weekend is the runtime ofboth procedures. If a Unicode conversion already results in 30 to40 hours of downtime despite the use of all possible optimizationmethods, a combined procedure with all the necessary prepara-tion and postprocessing within 48 hours will be possible only invery occasional cases. As a result, either a longer downtime mustbe accepted, or the alternatives described in the previous pointsmust be selected.

A combined solution also means a significant increase in the com-plexity of the project. The procedure for an upgrade alone is welldocumented in great detail, and there is also documentation ofseparate Unicode conversion. The integration of the two projectsrequires detailed planning for which there is currently very littlebackground information available. An example might be the han-dling of ABAP objects during an upgrade, with conversion startingfrom release SAP R/3 4.6C.

� Combined Upgrade & Unicode ConversionCombination of the upgrade from SAP R/3 4.6 C with a Unicode conver-sion

This CU & UC method was primarily developed for MDMP cus-tomers who have SAP R/3 4.6C as their source release and areworking towards a technical upgrade to SAP ERP 2005. In SAPNote 928729, the releases supported and their limitations aredescribed in more detail.

A significant component of this technology is the use of Transac-tion SPUM4, which represents an equivalent to Transaction


250


SPUMG under SAP R/3 4.6C (see Section 3.3.2). This is necessarybecause the principle behind Transactions SPUMG and SPUM4 isthat the transaction will be performed online during productionoperation. Because the runtimes of Transaction SPUMG forMDMP customers will run at least for a matter of days, the perfor-mance of SPUMG in the target release is impossible during thedowntime. Thus SPUMG was implemented in SAP R/3 4.6C asSPUM4, so that online performance would be possible under thisrelease.

In contrast, Unicode enabling (Transaction UCCHECK, forinstance) is not possible under SAP R/3 4.6C. This preparationstep must be performed on a sandbox system on a Unicode-capa-ble release (on non-Unicode or Unicode). The results can then betransported into the production system after the upgrade is com-plete.

Figure 4.3 shows a schematic diagram of one possible procedurefor a CU & UC. In the sandbox system (SBX), the Unicode enablingmust first be done, and the results can then be used in the PRDsystem after the upgrade is complete. The upgrade and Unicodeconversion in the sandbox system can alternatively be performedseparately in the initial step so that the UCCHECK activity can pro-ceed on the non-Unicode system.

Figure 4.3 Sample Procedure for CU & UC

PRD

SBX

4.6C

SPUM4

ERP 2005

UCCHECK

ERP 2005

Upgrade and Conversion

Upgrade and Conversions

4.6C

SPUM4 PREPARE

Copy

SUMG

4.6C

Unicode

Non - Unicode Time

Results


251

System Consolidation 4.4

� Twin Upgrade & Unicode ConversionCombination of upgrade and conversion for R/3 systems with Release < 4.6C

CU & UC cannot be performed for source system releases prior toSAP R/3 4.6C. In order to provide a solution for these customers,the method TU & UC has been developed. In this procedure, a par-allel twin system is constructed as a copy of the production sys-tem, and an upgrade is performed without Unicode conversion(see Figure 4.4)

Figure 4.4 Sample Procedure for TU & UC

Transaction SPUMG can now be run on the copy. The results arethen transferred to the production system for a productionupgrade before the Unicode conversion and used there. Here,there is a delta (table entries that have entered PRD after the con-struction of the twin system), which becomes larger the older thesystem copy of the production system. As a result, you must takeinto account the fact that the tasks after conversion (SUMG) willtake more time.

In SAP Note 959698, the releases supported and the limitations ofTU & UC are described in more detail.

4.4 System Consolidation

Simplification of the system landscape

For the purpose of simplifying the system landscape, there areefforts on the part of many customers to reduce the number of exist-ing systems. One option is to integrate systems with similar applica-tions but which have been constructed for other countries into one

PRD

4.6B TWIN

4.6B

ERP 2005

UCCHECK +SPUMG

ERP 2005

Upgrade

4.6B

Copy

Upgrade andConversion

SUMG

Unicode

Non - Unicode Time

Results


252


existing system. Here there is an opportunity to use a Unicode sys-tem as a basis.

In general, the systems to be migrated are non-Unicode systems, andconversion of the data during the migration would be desirable andusually possible. MDMP systems are again an exception in thisrespect, as the conversion is not as simple as for a single code pagesystem. The SPUMG logic can currently not be used for a data migra-tion.

Client migrationserver

SAP System Landscape Optimization has plans for tools which willmake it possible to migrate from SAP R/3 4.6C (non-Unicode) to SAPERP 2005 (Unicode). So here, three steps—an upgrade, a Unicodeconversion, and a system consolidation—will be combined into one.The technology used will be called the Client Migration Server, orCMIS. For more complete and up-to-date information, you can con-sult the SAP Service Marketplace (http://service.sap.com/slo).

4.5 Summary

The focus of this chapter has been the planning for Unicode conver-sion in a complex system landscape. A new installation is relativelysimple, because it hardly differs from the installation of a non-Uni-code system. In the conversion of a three-system landscape, on theother hand, there are already many different options for the imple-mentation of Unicode.

An estimate of the effort of the Unicode project is not possible with-out exact knowledge of a variety of factors. Here, database size, thepossible use of MDMP, the number of custom programs, and thetype and number of interfaces all play significant parts. A compari-son of Unicode conversion with an upgrade project made it clearthat, depending on the conditions, the Unicode conversion may eas-ily take as much time as a release upgrade. A combined upgrade andconversion procedure is available for customers, but the complexityof such a project should not be underestimated.


313

Index

#Replacement character 172

1:n relation 2727-bit ASCII 16

A

ABAP 128ABAP Editor 129ABAP enabling 114ABAP programming 134ABAP stack 160, 167ABAP text pool entries 264ABAP/Unicode check 148Address versions 271, 272Adobe Document Services 221ALE 136, 305ALE communication scenario 202ALE distribution model 187ALE inbound processing 188ALE message type 187, 193, 202

Multilingual 202ALE prototype 187ALE Unicode scenario 191, 193, 202Alignment gaps 134Ambiguous blended code page 40, 70ANSI 305API 305Append structure 115, 140Application server 175, 305Archiving 238ASCII 162

German 306Asian Double-Byte languages 131, 161Asian languages 157Asynchronous transmission 305

B

Backup 305BAdI 149Basic IDoc type 193BCP → Blended code page 305BDC 305BDocs 180, 182, 204

BIDI technology 30, 305Big Endian 51, 305Big Five 35Binary file 305Bit option 172Black box 136Blended code page 109, 111, 112Blended code page systems 39BOM 305BRIC countries 110BTF 305Business address services 272Business Server Pages 54Byte 305Byte-swapped 305

C

Cascading Font Generator 228Cascading fonts 107, 227, 228Case 305

Lower 305Upper 305

CBL 305CGI 305Character 28, 132

Asian 146Character composition 34Character elements 28Character encoding form 305Character encoding scheme 306Character rendering 218Character set 28

ASCII 162Global 32Vietnamese 221

Character-based data types 163Charlen 161CJK 306CJKV 306CL_ABAP_CHAR_UTILITIES 144CL_ABAP_CONTAINER_UTILITIES 146CL_ABAP_CONV_IN_CE 146CL_ABAP_CONV_OUT_CE 146CL_ABAP_CONV_X2X_CE 146


314

Index

CL_ABAP_LIST_UTILITIES 146CL_NLS_STRUC_CONTAINER 138CL_NLS_STRUC_CONTAINER_OFFS

139CL_NLS_STRUC_CONTAINER_SNAME

138Client migration server 252CMIS 252CMOD 214Code Inspector 147, 151Code page 16, 27, 28, 306

GB2312 285ISO 8859 279, 280, 281, 282, 283ISO Latin-11 284JISX208 285KSC5601 285Microsoft 1250 280Microsoft 1251 282Microsoft 1252 280Microsoft 1253 282Microsoft 1254 283Microsoft 1255 283Microsoft 1257 281Microsoft 874 284

Code page scanner 67Code page tables 279Code point 28Common character set 16, 20Communication

Homogeneous 156, 161Inhomogeneous 156, 161

Communication code page 164Determining 165

Communication IDoc 187Communication language 184Communication scenario

Unicode/MDMP 203Communication technologies 177Communication type 170Communication with RFC 161Consistency check 76Consolidation plans 248Container alignment 136, 140, 197

For Asian Double-Byte languages 196Container problem 137Container technology 136, 197Conversion errors 144Conversion of complex landscapes

Criteria 247

Conversion process 156Conversion projects 234Conversion sequence 236Conversion strategies 236Conversion times 96CORBA 49Cost estimate 242Country customizing 269Country-specific information 300Coverage Analyzer 147, 150CPU 306Cryptography 307CU & UC 111, 113, 249Currencies 15Customer namespace 191Customizing

Language-dependent 266Customizing includes 140

D

Data transfer 24Multilingual 168

Data typeLANG 168

Data typesCharacter-based 163Character-type 131, 132Non-character-type 131Numeric 132

Database code page 29DBCS 306DDIC attribute

Text language 71Deep data types 163Default set 287Delta problems 88Development freeze 246Device types 228Dialects 217Distribution monitor 99DMEE 173Double Byte Character set 306Double-Byte 34, 39Double-Byte code page 16, 279Double-Byte languages 132, 136, 197Downtime 249Dynamic code-page switch system 41


315

Index

E

EBCDIC 29, 306eCATT 306ECMAScript 49EDID4-SDATA 136EDIFACT 306Effort category 219Encoding

Hexadecimal 28Encoding form 306Encoding scheme 306Endianess 52, 157, 162End-user training 246Enterprise Services Architecture 53Enterprise SOA 53, 54Estimate of effort 236EUC 306Evaluation phase 234Expansion

In new countries 275Export 90Export control table 76Extension category 140Extractor jobs 213Extractors 180

F

F1 converter 163Failover 306Fallback code page 70File interfaces 142File transfer 142Flat data type 163, 167Font 306Fool the system 38, 279Front end 218Front-end code page 29FTP 306

G

GB2312 35German ASCII 306Global character set 32, 162Global master data 23Globalization 13Glyph 306

Golden MDMP rules 45GUI 306GUI_UPLOAD/DOWNLOAD 175

H

Handshake 165Hangul 306Hexadecimal encoding 28Hint 84Homogeneous communication 156, 161HPUTF8 226HTML 307

I

I18N 223I18N mode 101I18N option 226IDoc 136, 307IDoc adapter 160IDoc base type 187IDoc data transfer

Multilingual 197IDoc structure 188, 192, 193, 196, 198

Language-dependent 192, 197IMIG 99Import 91Inbound processing 186, 188, 191, 198,

199, 201INDX-type tables 69Information acquisition 235Inhomogeneous communication 156,

160, 161, 197Input method 220Input method editor 218Interface catalog 237Interface technology 177Interfaces 307

Minimization 247Internal language key 225International address versions 272Internationalization 13Internet Transaction Server 53, 307ISCII 307ISO 307ISO 8859 27, 28, 32, 35, 39, 40ISO Latin-1 16ISO/IEC 10646 19


316

Index

ISO-639 218IT solution

Global 275iView 54

J

J2EE 307Java 21, 49Java stack 95, 160, 167JDBC 307

K

Kanji 307Katakana 307Keyboard layout 220KSC5601 36

L

LandscapeMixed 58

LANGData type 168

Language CD 264Language determination

Methods 83Language import 256, 264, 266Language installation 256Language key 43, 218

Internal 225Language transport 262Language vector 225Language-dependent

IDoc structure 192, 197Language-dependent customizing 266Language-dependent object 256Language-dependent tables 167Languages 15Latin-1 character set 32Latin-4 307LDAP 49Legacy mode 143Length access 134Length programming 134Letters 28LEXUTF8 226Little Endian 51, 307

Load balancing 307Locale 40Localization 13Logon language 165, 174Long text editor 261Long texts

Multilingual 187LSB 307

M

Maintenance landscape 244Markup 307Master data

Global 23Master IDoc 187Master language 113MBCS 307MDMP 37, 38, 41, 111MDMP partner system 170MDMP rules

Golden 45MDMP system 41, 45MDMP/MDMP communication 164MDSP system 40Message broker 308Message queuing 308Message type 188, 193, 195, 204Microsoft MS 1250 29Microsoft MS 1251 27Middleware 156, 182, 308Migration monitor 97Mixed code page system 41MNLS 39MNLS system 38Modification 149Modification degree 185MSB 308Multi Byte character set 308Multi Byte languages 34, 197Multilingual ALE message types 202Multilingual data transfer 168Multilingual IDoc data transfer 197Multilingual long texts 187

N

Nametab 65New installation 233


317

Index

NLS_GET_LANGU_CP_TAB 139NNTP 308Non-Unicode system 129

O

ObjectLanguage-dependent 256

Object time 15Octet 308ODBC 308Offset access 134Offset programming 134Online repository texts 261OS 308OS/DB migration 61, 244, 275Outbound processing 186

P

Partner systems 158Patch 308Patterns 83PC UI 54PCL 308Peripheral code pages 29PI components 204Plain text 308Plug-in components 204Portal 308PREPARE 115Print drivers 221Printed characters 28Printing

In the Unicode system 106Production system 303Programs

Fenerated 149Generated 149

Project duration 241Project runtime 242Proof of concept 238Proposal pool 260

Q

qRFC 180, 204

R

R3load 91, 126R3up 117RADCUCNT 66, 116RAID 308RAM 308Reference language 269Release change 248Replacement characters 144, 172Reprocessing 87RFC 308RFC adapter 160RFC bit option 184RFC client 165RFC communication 161RFC communication code page 187RFC connection 169RFC conversion behavior 162RFC function 168RFC Unicode/non-Unicode communica-

tion 143Rich text 308RMI 308Round-trip capable 112, 215RSA6 211RSCP_CONVERT_FILE 175RSCPINST 223RSREFILL 268Runtime optimization 239RZ10 148, 225

S

Sandbox conversion 243SAP .NET Connector 160SAP applications

Unicode capability 61SAP Business Suite 111SAP Country Versions 14SAP ECC 6.0 110SAP Employee Self-Services 112SAP ERP 2004 111SAP ERP 2005 110, 111SAP Globalization Services 300SAP GUI 100, 144, 175

Release 6.40 175SAP Java Connector 160SAP language package 254


318

Index

SAP logon 101SAP Manager Self-Services 112SAP NetWeaver 2004s 110SAP NetWeaver Exchange Infrastruc-

ture 160SAP R/3 Enterprise 111SAP Smart Forms 221SAP Transport Management System 261SAP Unicode workshop 234SAP Web Application Server 128SAP Workplace 53SAP_CODEPAGE 165sapiconv 175SAPinst 126saplpd 228SAPscript 221SAPup 117SAPWIN 228SBCS 308SCI 151SCOV 150Script 308SE63 222, 226, 260, 261Secure Network Communication 46Semiautomatic translation 260Service-oriented architecture 309Services 234Session language 165SET LOCALE 174setlocale() 40SGML 309Shift-JIS 309Short text editor 261Single code page systems 17, 32Single Sign-On 46Single-Byte code page 16, 279Sizing 309SJIS 35, 40, 309SJIS code page 39SLO 309SM30 226SM59 143, 169SMLT 226, 264, 267SMLT_EX 263SNC 46SOA 309Solution scenarios for Unicode/MDMP

communication 185SPAM 264

SPAU 115SPDD 115Special characters 16, 279Special options 169SPRAS 44SPUM4 115, 249SPUMG 68, 114SQL 309SSO 46Standard ALE transfer 187Statistics 260Step language 213Structures 132

Character-type 132Deep 132Flat 132Nested 132Non-nested 132

SUMG 68, 122Supplementation 266Supplementation language 256, 268,

269Supplementation logic 267Support package 63, 202Surrogate area 50SY-LANGU 174Synchronous transmission 309System code page 29, 35, 174System consolidation 251System landscape

Simplification 251System time 15System vocabulary 69, 78

T

Table split 98Table structures 167TABLES 168Target code page 163TCP/IP 309TCP0C 164, 165TECHED_UNICODE_EXERCISE 150TECHED_UNICODE_SOLUTION 150Text language

DDIC attribute 71Text language flag 168Third-party software 233Time zones 15


319

Index

TIS620 36TOOLIMP4_UCMIG 118Transfer structure 180Translation

Manual 271Of business data 253Semiautomatic 260

Translation gaps 266Translation strategy 220, 222Translation tools 259Translation transports 262Translation Workbench 66, 261Transmission

Asynchronous 305Synchronous 309

TransportUnicode/non-Unicode 107

tRFC 186, 187tRFC connection 197TU & UC 111, 251Twin system 251Two-server methods 97

U

UCCHECK 115, 147, 238UCMIG_REQINC 118UCMIG_STATUS_CHK1 120UCS 309UM4_TXFLAG_UPLOAD 120Unambiguous blended code page 39Unicode

New installation 233SAP notes 301

Unicode architecture 57Unicode capability

SAP applications 61Unicode code page 19Unicode code point 28Unicode Consortium 22, 300Unicode conversion 60, 61, 304

Documents 303Hardware requirements 63Reasons 241Typical process 303

Unicode enabling 238Unicode encoding forms 20, 309Unicode encoding schemes 20, 50, 59,

309

Unicode flag 129Unicode font 227Unicode nametabs 114Unicode printers 107, 221, 226Unicode project 300Unicode scalar value 28Unicode standard 19, 22Unicode strategy 235Unicode system 129

Languages 287Unicode Transformation Format 20, 52,

309Unicode versions 22Unicode/MDMP communication

solution scenarios 185Unicode/MDMP communication scenario

203Unicode-specific introductions 300Upgrade 202User exit 149, 206User time 15UTF 309UTF-16 20, 51, 156UTF-8 20, 51, 156

XML intermediate format 163Utilities classes 144UUEncode 309

V

VAS 221Vietnamese character set 221Vocabulary maintenance

Variants 86Vocabulary transfer 82Voice over IP 310

W

W3C 310WE8DEC 29WML 49, 310Worklist 260Wrapper function 193WS_DOWNLOAD 144WS_UPLOAD 144WSDL 310


320

Index

X

XBRL 310XHTML 310XML 49, 310XRFC 163

Z

Zcsa/installed_languages 225
