Serialisieren und Deserialisieren der Funktionsaufrufe 

Verwendung

Ein wichtiger Aspekt für die Laufzeit ist der Aufwand für die Serialisierung und Deserialisierung der Funktionsaufrufe.

 

Voraussetzungen

Es gibt aus Sicht des RFC zwei Typen von Schnittstellen. Der Typ-1 ist eine Schnittstelle mit flachen Strukturen. Der Typ-2 ist eine Schnittstelle mit tiefen (verschachtelten) Strukturen. Der Typ-2 ist im bisherigen Verfahren aufwändig, da XML eingesetzt wird, um die tiefen Strukturen abzubilden.

 

Vorgehensweise

Die Typ-2 Aufrufe sollen verbessert werden, indem XML durch eine proprietäre aber performante Lösung ersetzt wird. Die Deserialisierung der Funktionsaufrufe einer Unit findet erst im Zielsystem statt. Dadurch ergibt sich, dass das Zielsystem bestimmt, in welchem Format die Funktionsaufrufe serialisiert werden müssen.

Aus diesem Grund wird in der Transaktion SM59 pro logische Destination hinterlegt, ob nach dem neuen oder klassischen Verfahren serialisiert werden soll. Bei der Verwendung von Receiver-Listen müssen alle Destinationen dasselbe Serialisierungs-Verfahren unterstützen. Falls ein oder mehrere Zielsysteme einer Receiver-Liste nur das klassische Serialisierungs-Verfahren unterstützen, dann muss für alle Destinationen, die in einer Receiver-Liste vorkommen können das klassische Verfahren eingestellt werden. Dies wird zur Laufzeit überprüft und führt gegebenenfalls zu einer Fehlermeldung mit Laufzeitfehler.

 

Ergebnis

Diese Vorgehensweise dient dazu, dass die Nutzdaten einer Unit nur einmal in der Datenbank abgelegt werden müssen.

 

Beispiel

Zu einem späteren Zeitpunkt könnte ein Konverter angeboten werden, der beim Versenden der Daten das Format entsprechend dem Zielsystem anpasst. Dadurch könnte die zuvor beschriebene Restriktion bei Receiver-Listen entfallen.