The RFC performs the conversion between different technical formats (integer display, Little versus Big Endian, and so on), as well as between code pages of sender and recipient.
If two SAP systems with different code pages exchange data with each other, and these systems do not use Unicode code pages, the code page conversion is performed at the receiver system. The binary codes of characters that cannot be converted into the code page of the receiver system are retained.
If two SAP systems with different code pages exchange data with each other, and where one of these systems uses a Unicode code page, the code page conversion is always performed at the system that uses the Unicode code page. The binary codes for characters that cannot be converted into the non-Unicode code page are replaced by a replacement character.
If two SAP systems in the same code page (non-Unicode or Unicode) exchange data with each other, the RFC only performs the technical conversions and no code page conversion.
The RFC between a Unicode system and a non-Unicode system has to convert the text data between the code pages used on both sides. Here, the following situations are possible:
An input character cannot be converted into the output code page.
Example: A Chinese Unicode character cannot be displayed in any European code page according to ISO8859.
The conversion leads to an overrun of the output buffer.
Example: A sequence of Japanese Unicode characters may cause an output buffer of the same length to overrun, when converting into the Japanese multibyte code page SHIFTJIS.
Characters in the input data are incorrect; for example, in non-Unicode multibyte code pages, not all combinations of 2 bytes are permitted.
Example: The Japanese code page SHIFTJIS (SAP number 8000) is a multibyte code page that has byte pairs whose first half lies in the range 0x80-0xEF, and whose second half lies in the range 0x40-0xFC. All other byte pairs are illegal and therefore cannot be converted. Data containing characters of this kind are therefore already incorrect before conversion. They may have entered the system from outside, through uncontrolled channels, or may be the result of using unsuitable text processing operations in the system.
If the RFC is place between a Unicode system and a non-Unicode system with multiple code pages (MDMP system), the data is available on the MDMP side in different code pages. In this case, the RFC takes into account the language keys included in the date, and assigns the code page used in the MDMP system to each language.
The procedure described here is applied to tables of type 1 (these tables normally have a flat row structure). The RFC transmits deep structures in XML, and codes the text data in UTF-8. If a non-Unicode system receives data like this, it converts it into the code page for the logon language. If a non-Unicode system sends this type of data, it converts it from the code page that is currently set.
The language-compatible conversion of the data takes place in the Unicode systems. Here, the Unicode systems emulate non-Unicode systems, thereby ensuring compatibility with old non-Unicode systems (downward compatibility).
During conversion, the Unicode system assigns the MDMP code page to the languages, as follows:
MDMP system calls Unicode system |
The MDMP system passes on its assignment of languages to code pages in the RFC log. For older MDMP systems, the Unicode system uses a predefined assignment list. |
Unicode system calls MDMP system |
The assignment is specified in the Unicode system, for the RFC destination. Transaction SM59 enables you to display and maintain the assignment. |
The RFC gets the language from the LANG fields in transported tables of type 1. Every relevant LANG field is flagged as a text language by a DDIC attribute. Transaction SE11 enables you to display and maintain this indicator.
If one structure uses .INCLUDE or .APPEND to refer to another structure with LANG fields, the indicator in the structure making the reference must also be reset; the structure being referenced can be opened and displays the indicator field that can be maintained.
In a structure with a 1 LANG field, this implicitly serves as the text language. When this type of structure is created, the DDIC attribute is activated. This setting can be reset in transaction SE11.
Note
If tables are defined as deep structures in an import, export or changing parameter, then the language is not evaluated.
If a structure does not have a LANG field, or if none of the LANG fields are flagged as the text language, the Unicode system performs the conversion as follows:
MDMP system calls Unicode system |
According to the code page specified by the sender |
Unicode system calls MDMP system |
Converts to the non-Unicode code page that is normally assigned to the logon language (in the Unicode system). You also have the option of using the logon language for the RFC destination (instead of that of the current context), by making a special setting for the RFC destination in SM59 call transaction SM59 and selecting the RFC Bit Options for this destination on the Special Options tab page in section Special Flags. Then select the checkbox Determined Communication Code Page (hexadecimal value 0x200). |
Note
In particular, IDocs that are used in the ALE interfaces do not have a language ID.
The transferred data might contain a language that is unknown in the MDMP system configuration. This can occur in both transfer directions, and independently of the client/server role of the systems involved.
Data may also contain a LANG field with the value " " (space), although this value is invalid according to the value table. Here, the same rules apply as for structures without LANG fields (see above).
Unicode system calls MDMP system |
The RFC terminates with the error SYSTEM_FAILURE. In this case, you can activate the user trace (SM04), in whose output you can find information about the unknown language. |
MDMP system calls Unicode system |
The RFC terminates with the error SYSTEM_FAILURE and sets the error message to "Connection closed (no data)". You can find the unknown language by activating the user trace in the MDMP system (SM04), repeating the RFC, and analyzing the trace files of the called Unicode system. |