Code Pages
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.
In the case where two SAP systems that have different code pages exchange data with each other, and where these do not use Unicode code pages, the code page conversion is performed on the receiver system side. The binary codes of characters that cannot be converted into the code page of the receiver system are retained.
In the case where two SAP systems that have 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 on the side of the system that uses the Unicode code page. The binary codes of characters that can not be converted into the non-Unicode code page, are substituted with replacement characters.
In the case where two SAP systems of the same code page (non-Unicode or Unicode) exchange data with each other, the RFC only performs the technical conversions, no code page conversion.
RFC and Unicode
The RFC between a Unicode system and a non-Unicode system must convert the text data between the code pages that are use 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 following 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 that contains characters such as these are therefore already incorrect before the conversion; they may have entered the system from outside, through uncontrolled channels, or may have arisen from using text processing operations in the system that are unsuitable.
RFC Between Unicode Systems and MDMP Systems
If the RFC takes place between a Unicode system and a non-Unicode system that has multiple code pages (MDMP system), then 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 (in principle, these are tables that have a flat row structure). The RFC transmits deep structures (structures that have at least one table type; see section BC-ABAP Dictionary, Types, Structures in the online documentation) in XML, and codes the text data in UTF-8. If a non-Unicode system receives such data, then it converts it into the code page of the logon language. If a non-Unicode system sends such data, then it converts it from the code page that is currently set.
The language-related conversion of 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 the conversion, the Unicode system assigns the MDMP code page to the languages as follows:
MDMP system calls Unicode system |
The MDMP system
sends its assignment of languages to code pages within the RFC log. |
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. |
Structures with LANG Fields
The RFC gets the language from the LANG fields that are included in the transported tables of type 1. In each case, the 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, then 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 that has 1 LANG field, this implicitly serves as the text language; when such a structure is created, the DDIC attribute is activated. This setting can be reset in transaction SE11.
If
tables are defined as deep structures in an import, export or changing
parameter, then the language is not evaluated.
Structures Without LANG Fields
If a structure has no LANG field, or if none of the LANG fields are flagged as the text language, then the Unicode system converts in the following way:
MDMP system calls Unicode system |
Corresponding to the code page given by the sender |
Unicode system calls MDMP system |
Converts into the non-Unicode code page that is
normally assigned to the logon language (in the Unicode system).
|
In
particular, the IDocs, which are used in the ALE interfaces, do not have a
language ID.
Unknown Languages
The transferred data may contain a language that is unknown in the configuration of the MDMP system. 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)’. |