1

Unicode Conversion Preparation

This Presentation is MDMP / Ambiguous Blended Code page specific

Created By : Sumit Kothiyal Role : Basis Consultant

2

Conversion Preparation

This chapter explains the steps involved in the pre-conversion preparation of the MDMP / Unambiguous blended code page SAP Systems.

1. ABAP Preparation System: Web AS 6.20 non-Unicode.

2. Unicode enabled ABAP and C/C++ programs.

3

Upgrade Path to the Unicode ( R/3 Enterprise)

Concept: Before the database conversion to the Unicode is executed all the text data must be assigned the correct code page

4

Concept Contd:

Single Code Page Systems and Unambiguous Blended Code page systems are easy to get converted into Unicode.

MDMP and Ambiguous Blended Code Page systems conversion is complex in nature.

5

Why MDMP/Ambiguous Conversion is complex?

Look at the content of the MDMP System as shown in the below diagram:

6

Content of the Unicode system is as shown below in comparison to the above diagram:

7

Concept: Conversion Preparation

Code page assignment in MDMP/Ambiguous Blended Code Page Systems is complex because all the rows of the tables in the Database must be assigned a Code Page.

Solution of the above problem:

A). Use existing language keys

B). System Vocabulary = Word – Language assignment

( Word= contains characters outside common character set )

8

SPUMG : Conversion Preparation

Unicode Conversion: The transaction used for the conversion information which will be used during the export/import of the Database in the actual Unicode conversion to keep the data consistent.

9

SPUMG Contd.

This is actually a tool for the database analysis for collecting words without language or code page information. SPUMG creates control information which is later used for the conversion as explained earlier.

SPUMG consists of the several Scan levels:

Consistency checks

Tables without language information ( Table 1)

Tables with Ambiguous language information

Tables with language information.

Reprocess.

INDX Table Analysis.

INDX Table repair.

10

SPUMG: Language Lists

11

SPUMG Settings: Maintain the SPUMG settings and then initialize the worklist for the Consistency checks

12

Consistency Checks:

Classifies tables into tables with/without language filed information ( Table category 1 and 2 ).

Checks table consistency ( existence, access)

Writes control information to SPUMG control tables ( Table category, Language Field)

13

Tables without Language Information: This scan adds words to the system Vocabulary and all the all the tables without language ( Table category 2 )information are scanned.

14

Tables with Ambiguous Language Information: All the tables with language information ( Table Category 1 ) are scanned. Words with an ambiguous language are added to the System Vocabulary.

Only active if ambiguous language list has been maintained.

15

System Vocabulary

System vocabulary must be maintained before the database is exported.

You can do the following:

Insert the language keys automatically on scan level tables with language information.

Create the Vocabulary hints to assign the language based on the other table fields.

Manually assign the language to word in the system Vocabulary.

Reuse the existing language code page assignments imported from the other systems or delivered by the SAP (sapnotes 756534 and 756535 )

16

Tables with Language Information: All tables with the language information are scanned ( Table category 1 ). This scan assign the language to the words in the System Vocabulary based on the values of the other tables in the database.

Only problem could be Vocabulary Collisions.

17

Reprocess: This scan simulates the R3load behavior. It checks if the code page information in the System Vocabulary is sufficient for the conversion. If not, this scan creates a repair Log for the table. ( Row identifier + Language assignment )

18

Reprocess Repair Log : It contains table name, key values, reason why no code page could be assigned. Users can assign a language to each entry here. This information is used in the Unicode system to repair wrongly converted data.INDX-type Tables: Special Treatment

Why must these tables be scanned separately ?

The answer is these tables consists of : 1. A transparent part which is treated like the other transparent tables in the database during the conversion preparation. 2. A binary part which contains the code page information used during the Export to database/Import to database statement.

Note :In MDMP systems the previous handling of the INDX-type tables was improper in a way that a wrong code page might be stored in the binary part of the table.

19

Structure of the INDX-type tables as shown in the below diagram:

20

INDX-type table repair/analysis : These two scans treat the binary part of INDX-type tables:

1. All INDX-type tables without language information are scanned and all the text hidden in the INDX-cluster part is analyzed. Words are added to the system Vocabulary.

2. System Vocabulary is used for assigning correct code pages before the database export.

21

Final steps in the non-Unicode systems

Newly created tables can be added to SPUMG by updating the Worklist. You can display the new tables in the update log.

22

Database Export, Conversion and Import

The system setup tool SAPinst is used for the entire system copy – internally SAPinst uses the program R3load.R3load performs the database export with the conversion to Unicode using the control table and System Vocabulary, writes an R3load Repair log in case the code information is not available, and performs the database import. As a system copy to Unicode, database conversion and system shutdown / Unicode system start will be completely automated.

23

R3load – Export :

SAPinst uses a program R3load as a Frontend tool for the database export.

Logs are written to the SAPinst Directory

Export files are written to the Export Directory

R3load – Import :

SAPinst uses a program R3load as a Frontend tool for the database import.

Non-UC DB can be deleted ( not recommended) or UC DB can be installed on the new / different server.

Import method is same as new installation.

24

R3load – Export

Export phase as Shown in the diagram below:

25

R3load -- Import

Import phase as Shown in the diagram below:

26

Unicode System: Initial Steps

1. Update the kernal and other executables

2. Start the Server.

3. Logon to the Unicode System and run SICK.

See the diagram below for the overview:

27

SUMG: On the UC System

SUMG: Post- conversion repair in the Unicode converted system

28

SUMG: After the database import there might be some data in the Unicode system which need to be “repaired”. In this case the data can be converted again, using the correct language information (code page).

SUMG has several repair methods:

1. Repair Jobs, using the R3load Repair Log and the language information of the SPUMG reprocess Log.

2. Repair Hints.

3. Manual Repair.