SAP Unicode FAQs

You have questions on Unicode

Other terms

Unicode;MDMP;SPUMG

Reason and Prerequisites

Info on Unicode needed

Solution

This SAP note provides some hints based on best practices and SAP experiences. Please note that this is a consulting note and answers can vary depending on specific customer requirements. Therefore we recommend to contact your SAP Unicode consultant in case of doubts.

1. What are the main sources of Unicode information at SAP ? What is the best approach to get familiar with the topic ?

              The following Quick Links provide general information on Unicode:

a) http://service.sap.com/unicode (especially the Unicode Media Library)

b) http://www.sdn.sap.com/irj/sdn/i18n > Unicode

c) http://www.sdn.sap.com/irj/sdn/unicode-conversion

d) https://forums.sdn.sap.com/forum.jspa?forumID=287

              Collection of specific Info on Unicode:

e) Unicode Definition:

                       http://en.wikipedia.org/wiki/Unicode

f) Unicode Conversions of SAP systems including project info

                       http://service.sap.com/UNICODE > Unicode Media Library > Unicode WS and general Unicode Info > October 2008: Unicode Conversion Topics

g) Examples for customer experiences on Unicode Conversions

                       https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/00709c2a-5f0c-2b10-adb5-98664277ad4e

                       https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/1d5b8123-0a01-0010-90a7-f1c9622e3d89

                       https://weblogs.sdn.sap.com/pub/wlg/8611

                       http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/13106

                       https://wiki.sdn.sap.com/wiki/display/unicode/Challenges+in+BI+Unicode+conversion

h) Unicode Technical FAQs

                       https://service.sap.com/~sapidb/011000358700002820632002E

i) Unicode Collection Note

                       See SAP Note 1319517.

j) Book: Unicode in SAP Systems

                       http://www.sap-press.com/product.cfm?account=&product=H1984

k) Upgrade and Unicode Conversion

                       http://service.sap.com/UNICODE > Unicode Media Library > Unicode WS and general Unicode Info > May 2009: Combined Upgrade and Unicode Conversions

l) ABAP Programming in unicode Environment / Unicode enabling Guide

                       http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/b02d3594-ae48-2a10-83a7-89d369b708e5

m) MDMP Conversion Concept

                       See SAP Note 1037613.

n) Unicode Conversion Kit

                       See SAP Note 1149417.

o) Unicode Conversion Guide / Trouble Shooting Guide

                       See SAP Notes 765475, 551344, 1051576, 928729 and/or 959698.

                       

2. Should I install a new system on Unicode or non-Unicode?

              All SAP Netweaver 7. 0 based systems must be installed on Unicode only.

3. Which SAP graphical user interface (GUI) version can be used in a Unicode system?

              The recommended version is SAP GUI 7. 20 with the latest patch level. SAP GUI 6.20 with the latest patch level is also possible, but has more restrictions. For Asian Windows clients, you have to use SAP GUI >= 6.40. Note that older patch levels might also be possible with additional restrictions. For further information, see SAP Notes 508854, 673244, and 710720.

4. Which releases are available on Unicode?

              All current releases of SAP applications based on SAP Netweaver support Unicode.

              For information on earlier releases, see Quick Link /unicode > Unicode Media Library > Unicode Information on specific Topics > Unicode Availability and ERP Language Technology Support.

              For conversion availability, see also SAP Note 548016.

5. What are the advantages of Unicode ?

a) Unicode is the strategic direction of SAP for all applications.

b) Proper usage of JAVA is only possible with Unicode systems (for example, ESS/MSS or interfaces to Enterprise Portal).

c) Proper usage of WWW interfaces is only possible with Unicode systems.

d) All non-R/3 solutions are only available with Unicode (or possibly with single code page).

e) SAP ERP 6.0 is not supported anymore with MDMP (see SAP Notes 79991 and 73606).

6. What are the restrictions of Non-Unicode systems on single code pages (e.g. Western European code page) ?

              Please have a look at SAP notes 73606, 838402, 975768, 1358929, 1503523 and 1513496. SAP considers Unicode as the strategic direction. Therefore it is very likely that new technical solutions will be supported on Unicode ONLY.

7. How does SAP support kernel patches, Support Packages, and language import files in Unicode and Non-Unicode systems?

a) In case of a Unicode system, a Unicode-specific kernel must be used. This is one of the rare example where two different components (Non-Unicode and Unicode) exist.

b) Most other areas - such as Support Packages, language import files, Add-Ons, ... etc. - are based on non-Unicode by default, but can be used for both non-Unicode and Unicode solutions. A conversion is triggered during import.

8. Which SAP Notes are important for a Unicode conversion or implementation?

              Refer to SAP Note 1319517 and Unicode conversion guides (last section) attached to notes 551344, 1051576, 928729 or 959698.

9. Is it possible to transport between a non-Unicode and a Unicode system?

              In general, it is possible to transport between non-Unicode and Unicode systems. Restrictions apply for characters or language keys not supported in the non-Unicode system and in case of an MDMP system on the non-Unicode side. Transports between SAP systems on releases 4.6C or lower and Unicode systems are not possible. For detailed information, refer to SAP Notes 638357 and 330267.

10. What happens when data is transferred between non-Unicode and Unicode SAP systems via Remote Function Call (RFC)?

              RFC automatically converts data if data is transferred in mixed landscapes, whenever this is possible (meaning that the non-Unicode supports the character). Restrictions exist in the case of an MDMP system (see also SAP Note 745030).

              In addition to the transport behavior (described before), this means that mixed landscapes are supported as much as technically possible. However in such landscapes there is always the risk of data loss - therefore SAP recommends to go for Unicode in all systems of your landscape (longterm).

11. Is it possible to exchange data between an MDMP and a Unicode system via Application Link Enabling (ALE)?

              There are several restrictions; refer to SAP Notes 656350, 745030 and 991763.

12. Is it possible to install a non-Unicode and a Unicode system on one physical server? What about MCOD?

              You can install two different SAP systems (one Unicode and one non-Unicode) on one physical server. However, SAP does not support mixed non-Unicode and Unicode data in a "Multiple Components in One Database" (MCOD) solution.

13. Is IDES available on Unicode?

              Yes, SAP ERP 6. 0 IDES is available on Unicode only. For further information see SAP Notes 799639 and 956921.

14. What are the disadvantages of having a Unicode development system and a non-Unicode production system?

              Technically, objects can be transported from a Unicode to a non-Unicode system, but Unicode supports about 95,000 characters whereas non-Unicode supports less - so when a non-supported character is transferred from Unicode to non-Unicode, this is converted by default to "#". Also, if the production system is an MDMP system, texts that do not have language keys will be converted on the basis of a single code page - data from other code pages will not be converted properly. Lastly, the interface behavior between non-Unicode and Unicode systems is different and therefore the development system does not exactly reflect the situation in the production system.

              SAP therefore recommends this mixed setup for a very limited time only.

15. What kind of basic documentation do customers need to convert an SAP system to Unicode?

a) Release-dependent Installation Guide and corresponding SAP Note

b) Release-dependent System Copy Guide and corresponding SAP Note

c) Release-dependent and Basis-Support-Package-dependent Unicode Conversion Guide and SAP Note 548016 (See also notes 551344, 1051576, 928729 or 959698).

              The system-copy procedure is the basis for the Unicode conversion. Therefore, documents in points 1 and 2 are mandatory for a Unicode conversion. Point 3 describes Unicode-specific activities that need to be completed during the process. As the system-copy procedure is also used for other purposes (such as OS/DB migrations), these documents are independent from the Unicode Conversion Guide. You must work with all three guides listed above; there is no overall conversion guide available since some information overlaps and would have to be updated twice or even three times.

16. What are the biggest challenges when my company converts to Unicode?

              The following points heavily influence the efforts required to perform a Unicode conversion:

a) Large databases/strict downtime requirements/slow hardware

                       The actual downtime is a result of the size of the database, the performance of the hardware, and the process optimization (for example, parallelization) during the conversion process. In order to restrict the downtime as much as possible, in most cases several sandbox conversions (with the hardware of the sandbox being identical to the PRD system) and detailed knowledge of the system-copy process are necessary.

                       For further information, see Quick Link /systemcopy

b) MDMP - Unicode interfaces

                       This type of interface requires much effort, so we recommend that you minimize the number of language-specific interfaces from Unicode to MDMP systems in your landscape.

                       For transferring data in both directions, adapting language-specific ALE interfaces requires more effort than adapting similar BW interfaces. The following rough classification regarding MDMP - Unicode interfacing effort can be made: JAVA > ALE > CRM > BW

                       Adaptation is necessary in both directions: Unicode to MDMP, and MDMP to Unicode.

                       For further information, see SAP Note 745030.

c) Interfaces in general: Non-SAP and SAP

                       A detailed analysis of all existing interfaces is necessary.

                       Unicode availability of third-party products and add-ons:"SAP certified" does not automatically mean that the solution is also Unicode-compliant. Therefore, you need to contact vendors as soon as possible in order to evaluate whether you can use the software in a Unicode environment. Extensive testing might be necessary. A specific Unicode certification is available, and those products are listed on the SAP Service Marketplace as Unicode-certified.

d) Unicode conversion of MDMP systems - with large number of installed code pages

                       In general, the more installed code pages you have, the greater the effort will be to convert. Assumption for the standard conversion case is that the Golden Rules for MDMP systems were followed (see SAP Note 73606). This is especially important for the rule that the logon language must be the same as the language of the entered data. "Fool-the-system" cases, such as logging on in English and inserting Russian data, will need more effort.

                       Latin 1 and Latin 2 only: The overlap between these code pages is rather high. For instance, the special German characters "ä,ü,ö,ß" are available in both code pages. Therefore, the system vocabulary tends to be smaller when you have this combination. But, as soon as an additional code page like Cyrillic is added, all language-independent texts containing any special characters (including the German ones) are added to the system vocabulary.

                       Latin 1 and one Asian code page: Usually data from - for example - Latin-1 and Shift-JIS (used in Japan) can be identified easily. In most cases, it is obvious that the data is either from Western Europe or Asia. This is also valid for the combination of Latin-1 and Russian or Greek (or Latin-2 instead of Latin-1). Also in this case, as soon as you add an additional code page, it becomes much more complicated to identify the texts.

                       A combination of two (or more) Asian code pages, and Russian or Greek: as all these code pages contain only special characters, the combination is rather complicated - since it is not easy to differentiate between texts from these code pages. The combination of simplified Chinese and traditional Chinese is one of the solutions which requires the most effort.

                       Blended code pages

                       - Unambiguous blended code pages: conversion is comparable to a single code-page conversion.

                       - Ambiguous blended code pages: conversion is comparable to an MDMP conversion. But in addition, at least English (and German in the European case) needs to be be treated as "ambiguous language." This means that even language-dependent texts containing special characters with EN as the language key will be added to the system vocabulary. Therefore the size of the vocabulary will be significantly higher in this case.

                       For detailed information, please have a look at the Unicode Conversion Guide.

e) ABAP enabling

                       The number and size of ABAP objects (such as reports) you use influence the effort. You can estimate (roughly) how much time you will need for your Unicode-enabling project based on the following information: If you know how many errors you have by running Transaction UCCHECK, you can calculate 30 errors per day per developer. Note that these numbers can differ significantly for individual systems; they highly depend on how the errors are distributed ("easy" versus "complicated" versus "non-analyzable" - see the next point for further details)

                       Three kinds of problems can be distinguished:

                       - "Easy" changes like "CS" changed to "BYTE-CS": these errors normally require minimum effort.

                       - More complicated problems, such as offset programming on HEX-byte-like data types: might require a redesign of the offset programming.

                       - Non-analyzable areas with dynamic programming: If the data type is determined dynamically during execution of the program, UCCHECK cannot detect errors. In this case, UCCHECK will show a yellow traffic light and extensive testing will be necessary.

                       For detailed information, check the following link:

                       http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/b02d3594-ae48-2a10-83a7-89d369b708e5

f) Conversion of systems with Asian or non-Latin-1 code page

                       If Latin-1 or Latin-2 is not used in the SAP system, but German should be used later in the Unicode system, it is necessary to import the German language after the successful Unicode conversion(see SAP note 922783).

17. How long will it take to convert a three-layer system landscape?

              There is no general answer to this question. Former project times varied from 2-18 months, highly dependent on the topics listed in question 16. Some comments:

a) If there are strict downtime requirements and these cannot be met easily with the available hardware, several iteration steps (sandbox conversion trials) might be necessary to enhance performance.

b) If many MDMP interfaces need to be adapted, this will affect the project timeline.

c) ABAP enabling might take longer if you have many customer-specific reports.

d) An MDMP conversion usually means more (manual) efforts compared to a single-code-page conversion.

e) In most cases, the Unicode conversion will be a project. From SAP's experience, it is not possible for existing staff to perform the conversion in addition to all other daily tasks. Project times are also highly dependent on the conversion project being made a high priority. Management commitment and support is mandatory.

18. What aspects does my company need to take into account when we convert an SAP system landscape with multiple productive systems ?

a) Perform ABAP enabling as soon as possible (e.g. in Non-Unicode systems).

b) Convert MDMP systems at first, if possible

c) Get an overview of all interfaces and types of data that are transferred.

d) Evaluate additional effort for MDMP - Unicode interfacing.

e) Perfom sandbox conversions for all productive systems.

f) Check Unicode compliance of third-party solutions as soon as possible.

g) Unicode systems support about 95,000 characters, whereas non-Unicode systems support less characters - so there is an evident restriction if non-supported characters are transferred to non-Unicode systems (these characters are usually converted to "#"). You should take this fact into account when you plan the landscape.  Since SAP Business Information Warehouse usually just receives data, this is a good first candidate for a conversion.

19. What should be tested after the Unicode conversion?

              We recommend a full regression test with focus on language-specific texts (texts with special characters) comparable to the tests after an upgrade. Customer experiences do show that SAP standard programs work properly in most cases; therefore, the main testing areas should be tests on:

a) Customer-specific programs

b) Modified SAP standard programs

c) Third-party solutions

d) All interfaces

              In case of an MDMP conversion, the proper language mapping in the system vocabulary should be tested.

20. Can archived data be displayed correctly after a Unicode conversion?

              Archived data is not converted during the conversion project. Non-Unicode archived data is converted online when it is accessed from the Unicode system. The logon language is used to determine the source (non-Unicode) code page of the archived data. This means that even in the Unicode system, the logon language has to "match" the code page of the accessed archived data. (For example, with logon in EN, archived Western European data (code page 1100) is displayed properly, while all other special characters are not; or with logon in JA, Shift-JIS data (code page 8000) is displayed properly, while anything else would not be.) This is very important in the case of former MDMP systems. For further information, see SAP Note 449918.

21. What are the hardware resource requirements on a Unicode system compared to those on a non-Unicode system?

              Please have a look at SAP note 1139642.

22. If my company converts to Unicode, do we have to adapt our non-Unicode printer landscape?

              The printing mechanism is the same in Unicode and non-Unicode systems. Therefore, after a Unicode conversion, existing printers will work similarly as they did in the non-Unicode system. But, non-Unicode printers will be still restricted to print only data from one "old" code page. If this is acceptible for you, then no further action is needed. For non-Latin-1 code pages, the printer will need to support the corresponding font (in non-Unicode and Unicode). This is normally provided by a cartridge.

              You could also use a Unicode printer; with it, you can print special characters from different "old" code pages on one printout. For detailed information, see SAP Notes 215015 and 750219.

              In addition, SAP notes 83502 and 1097990 provide additional info.

              Especially for double byte languages, shiftings can occur. please have a close look at the used font, which can be different between Unicode and Non-Unicode systems.

23. What hardware options do I have for performing a (standard) Unicode conversion of my production system?

              There are at least two possibilities to convert a production system to Unicode:

a) One-server solution: Do the export, delete the non-Unicode system, and install the Unicode system on the same (old) server

                       Advantages:

                       - No additional hardware needed

                       Disadvantages:

                       - Non-Unicode data is no longer accessible after the conversion; no comparison possible

                       - No parallel export and import possible

                       - If the server is not enhanced, the performance (for instance, response times) of the Unicode system might be problematic

b) Two-servers solution: Do not delete the non-Unicode system, but install the Unicode system on a second, new production server

                       Advantages:

                       - Downtime can be reduced by executing the export and import in parallel using the Migration or Distribution Monitor

                       - Non-Unicode system is still accessible after the Unicode conversion for comparison purposes

                       - Non-Unicode system can be used as instant back-up system at any time during the Unicode conversion

                       - Possible to use better hardware for the Unicode system; this will also reduce downtime during the import process

                       - Unicode database instance can be built up and prepared in advance during uptime

                       Disadvantages:

                       - Additional hardware needed

              SAP recommends the two-servers solution - especially for Unicode conversions of MDMP and/or very large systems.

24. Can my company perform ABAP enabling in a 4.6C system?

              No, this is not possible. You need to perform ABAP enabling in a SAP Web Application Server (SAP Web AS) 6.20-based system (or higher). Many Unicode-specific ABAP syntax enhancements do not exist in 4.6C. Also, the transaction UCCHECK used for Unicode enabling is only available in SAP Web AS 6.20 or higher.

              Therefore, our recommendation in this case is to build up a sandbox system, upgrade this system to a SAP Web AS 6.20-based system (or higher), and check the existing customer-specific reports with UCCHECK.

25. What is the purpose of the profile parameter abap/unicode_check and how can you use it in a conversion project?

              You can use the profile parameter abap/unicode_check to 'simulate' a Unicode system for the ABAP objects in a non-Unicode system. If you turn the profile parameter on, then all objects that do not have the Unicode indicator set will not work in a non-Unicode system (normally these objects would still work fine in a non-Unicode system). You can set this parameter in the landscape (for releases >= WAS 6.20 only) after the Unicode enabling is finished and automatically generated programs have been regenerated (see Unicode Conversion Guide). This ensures that you will detect missing Unicode indicators before the actual Unicode conversion takes place. Please also have a look at the documentation of this parameter in transaction RZ11.

26. What are the advantages and disadvantages of a combination of an Upgrade and a Unicode conversion ?

a) Advantages

                       - With a combination of both Upgrade and Unicode conversion, customers can benefit from synergies in testing. Integration testing is needed only once.

                       - Customers need to schedule one single downtime only.

                       - Many preparation tasks regarding upgrade and Unicode conversion can be done in parallel - therefore the overall average project times of Upgrades without Unicode conversion are typically not much lower than those with the combined approach.

                       - Feedback from customers indicate that a combination of both procedures has been done several times.

                       - Overall effort is typically smaller in case of combination.

                       - Based on experiences made in the past, many customers have successfully done a combined approach (both MDMP and single code page).

b) Disadvantages

                       - In case of a combined approach, customers mix two major procedures. In some cases it can be a challenge to distinguish errors due to the Upgrade and the Unicode conversion of each other.

                       - Downtime for combined approach might be longer than available downtime window.

27. What are the options to combine an Upgrade with a Unicode conversion ?

a) Combined Upgrade & Unicode Conversion (Abbreviation: CU&UC)

                       - Described in SAP note 928729

                       - Released for "standard MDMP" systems (see SAP note 928729)

b) Twin Upgrade & Unicode conversion (Abbreviation: TU&UC)

                       - Described in SAP note 959698

                       - Released for "standard MDMP" systems (see SAP note 959698)

                       - Used for MDMP systems - for a "standard single code page system", TU&UC does not make sense.

c) Sequential approach (first Upgrade, then Unicode conversion)

                       - Works for Single code Page systems only (Non-MDMP / Non-Blended code page)

                       - Logically separate the Upgrade and the Unicode Conversion. However both might be combined in one downtime, as in single code page conversion the time for preparation jobs in downtime does not take too much time.

                       - A typical example is to use this method in case of Non-ERP / Non-R/3 single code page systems

28. Is it possible to combine an OS/DB migration with a Unicode conversion ?

              Yes, it is possible to do this. Moreover it is highly recommended to consider a Unicode conversion when doing an OS/DB migration on a Non-Unicode system.

29. Where can I find information about SAP Unicode conversion Services ?

              Go to Quick Link /unicode > Service Offerings

If you have further questions, please send a mail to globalization@sap.com .
In addition, it might be possible to get answers via Unicode forum in SDN:
https://www.sdn.sap.com/irj/scn/forum?forumID=287