Codepages 

 

Der RFC führt die Konvertierung zwischen verschiedenen technischen Formaten (Integer Darstellung, Little versus big Endian usw.) sowie zwischen den Codepages von Sender und Empfänger durch.

 

Im Falle, dass zwei SAP Systeme unterschiedlicher Codepage miteinander Daten austauschen und diese keine Unicode-Codepages verwenden, wird die Codepage-Konvertierung auf der Seite des Empfängersystems durchgeführt. Die Binärcodes von Zeichen, die nicht in die Codepage des Empfängersystems konvertiert werden können, bleiben erhalten.

 

Im Falle, dass zwei SAP Systeme unterschiedlicher Codepage miteinander Daten austauschen und eines der beiden Systeme eine Unicode-Codepage verwendet, wird die Codepage-Konvertierung immer auf der Seite des Systems gemacht, das die Unicode-Codepage verwendet. Die Binärcodes von Zeichen, die nicht in die nicht-unicode Codepage konvertiert werden können, werden durch ein Ersatzzeichen ersetzt.

 

Im Falle, dass zwei SAP Systeme der selben Codepage (Nicht-Unicode oder Unicode) miteinander Daten austauschen, führt der RFC nur die technischen Konvertierungen und keine Codepage-Konvertierung durch.

 

RFC und Unicode

 

Der RFC zwischen einem Unicode System und einem Nicht-Unicode System muss die Textdaten zwischen den auf den beiden Seiten verwendeten Codepages konvertieren. Dabei können folgende Situationen auftreten:

• Ein Eingabezeichen ist nicht in die Ausgabe Codepage konvertierbar.
  Beispiel: ein chinesisches Unicode Zeichen ist in keiner europäischen Code Page nach ISO8859 darstellbar.
•  Die Konvertierung führt zum Überlauf des Ausgabepuffers.
  Beispiel: eine Folge von japanischen Unicode Zeichen kann bei Konvertierung in die japanische Multi-Byte Codepage Shift-JIS einen Ausgabepuffer gleicher Länge zum Überlauf bringen.
• Zeichen in den Eingabedaten sind falsch; zum Beispiel sind in Nicht-Unicode Multi-Byte Codepages nicht alle Kombinationen aus 2 Bytes zulässig.
  Beispiel: die japanische Codepage Shift-JIS (SAP Nummer 8000) ist eine Multi-Byte Codepage mit Byte Paaren, deren erste Hälfte im Bereich 0x80-0xEF, und deren zweite Hälfte im Bereich 0x40-0xFC liegt. Alle anderen Byte Paare sind illegal und daher nicht konvertierbar.
  Daten mit solchen Zeichen sind also bereits vor der Konvertierung fehlerhaft; sie können auf unkontrollierten Kanälen von außen in das System gelangt, oder durch Anwendung ungeeigneter Textverarbeitungsoperationen im System entstanden sein.

 

 

RFC zwischen Unicode- und MDMP-Systemen

Findet der RFC zwischen einem Unicode System und einem non-Unicode System mit mehreren Code Pages (MDMP System) statt, dann liegen die Daten auf der MDMP Seite in verschiedenen Code Pages vor. Der RFC berücksichtigt in diesem Fall die in den Daten enthaltenen Sprachschlüssel und ordnet jeder Sprache die im MDMP System verwendete Code Page zu.

 

Das hier beschriebene Verfahren wird auf Tabellen vom Typ 1 angewandt (Im Prinzip handelt es sich dabei um Tabellen, die eine flache Zeilenstruktur haben). Tiefe Strukturen (das sind Strukturen mit mindestens einem Tabellentyp; siehe Online Dokumentation Abschnitt BC-ABAP Dictionary, Typen, Strukturen) überträgt der RFC in XML Darstellung und codiert Textdaten darin in UTF-8. Empfängt ein non-Unicode System solche Daten, dann konvertiert es sie in die Code Page der Anmeldesprache. Sendet ein non-Unicode System solche Daten, dann konvertiert es aus der aktuell eingestellten Code Page.

 

Die sprachgerechte Konvertierung der Daten findet in den Unicode Systemen statt. Die Unicode Systeme emulieren dabei non-Unicode Systeme und gewährleisten damit die Kompatibilität mit alten non-Unicode Systemen (Abwärtskompatibilität).

 

Bei der Konvertierung ordnet das Unicode System den Sprachen die MDMP Code Page wie folgt zu:

MDMP System ruft Unicode System	Das MDMP System übermittelt seine Zuordnung von Sprachen zu Code Pages innerhalb des RFC Protokolls. Für ältere MDMP Systeme verwendet das Unicode System eine voreingestellte Zuordnungsliste. Diese Zuordnungsliste steht in der Dokumentation zur Transaktion SM59 RFC Destination definieren im Abschnitt Voreingestellte Code Pages.
Unicode System ruft MDMP System	Die Zuordnung ist bei der RFC Destination im Unicode System hinterlegt. SM59 erlaubt die Anzeige und Pflege der Zuordnung.

 

 

Strukturen mit LANG Feldern

 

Der RFC entnimmt die Sprache den LANG Feldern, die in den transportierten Tabellen vom Typ 1 enthalten sind. Das jeweils relevante LANG Feld ist durch ein DDIC Attribut als Textsprache gekennzeichnet. Die Transaktion SE11 erlaubt die Anzeige und Pflege dieses Kennzeichens.

Nimmt eine Struktur durch .INCLUDE oder .APPEND Bezug auf eine andere Struktur mit LANG Feldern, dann muss das Kennzeichen in der referierenden Struktur gegebenenfalls neu gesetzt werden; die referierte Struktur kann dazu aufgeklappt werden und zeigt das pflegbare Kennzeichenfeld.

 

In einer Struktur mit 1 LANG Feld gilt dieses implizit als Textsprache; das DDIC Attribut wird beim Anlegen einer solchen Struktur eingeschaltet Diese Einstellung kann in der Transaktion SE11 zurückgesetzt werden.

 

 

Werden Tabellen als tiefe Strukturen in einen Import-,  Export-, oder Changing Parameter definiert, so wird die Sprache nicht ausgewertet!

 

 

Strukturen ohne LANG Felder

 

Wenn eine Struktur kein LANG Feld besitzt, oder wenn keines der LANG Felder als Textsprache gekennzeichnet ist, dann konvertiert das Unicode System wie folgt

MDMP System ruft Unicode System

Entsprechend der vom Absender mitgegebenen Code Page

Unicode System ruft MDMP System

In die normalerweise der Anmeldesprache (am Unicode System) zugeordnete non-Unicode Code Page. Wahlweise kann durch eine besondere Einstellung der RFC Destination in SM59 die Anmeldesprache der RFC Destination (statt der des laufenden Kontextes) verwendet werden: wählen Sie dazu in der SM59 für diese Destination im Reiter Spezielle Optionen im Abschnitt Spezielle Flags die RFC Bitoptionen aus. Wählen Sie nun die Checkbox Ermittelte Kommunikationscodepage aus (Hexadezimalwert 0x200).

 

Insbesondere die IDocs, die in den ALE-Schnittstellen verwendet werden, verfügen nicht über ein Sprachkennzeichen.

 

 

Unbekannte Sprachen

 

Die übertragenen Daten können eine Sprache enthalten, die in der Konfiguration des MDMP Systems unbekannt ist. Dies kann in beiden Übertragungsrichtungen und unabhängig von der Client/Server Rolle der beteiligten Systeme geschehen.

Gelegentlich enthalten Daten ein LANG Feld mit Wert „ „ (Zwischenraum), obwohl dieser Wert gemäß Wertetabelle unzulässig ist. Hier gelten die gleichen Regelen wie für Strukturen ohne LANG Felder, siehe oben.

Unicode System ruft MDMP System	Der RFC bricht mit Fehler SYSTEM_FAILURE ab. In diesem Fall können Sie den User Trace (SM04) einschalten und finden in der Ausgabe Informationen über die unbekannte Sprache.
MDMP System ruft Unicode System	Der RFC bricht mit Fehler SYSTEM_FAILURE ab und setzt die Fehlernachricht auf „Connection closed (no data)“. Die unbekannte Sprache finden Sie, indem Sie den User Trace im MDMP System einschalten (SM04), den RFC wiederholen und die Trace Dateien des gerufenen Unicode Systems analysieren.

 

Technische Voraussetzungen