Show TOC Anfang des Inhaltsbereichs

Hintergrunddokumentation SOAP Message Transmission Optimization Mechanism (MTOM)  Dokument im Navigationsbaum lokalisieren

Allgemeines

Ein Vorteil für die Modellierung der Payload einer Message mit XML Schema ist, dass die übertragenen Geschäftsinhalte später in einer strukturierten und lesbaren Form übertragen werden können. Das Format der Payload ist also zeichenketten-basiert: Je nach verwendeter Code-Page können nur eine begrenzte Anzahl von Zeichen unterschieden werden.

Das Format von Binärdaten (Bilder, Audio-Dateien, Signaturen, und so weiter) ist kompakter als das zeichenketten-basierte Format der Payload, ist aber auf Grund des größeren Wertebereichs des Binärdatenformats nicht mit zeichenbasierten Code-Pages darstellbar.

Es gibt daher grundsätzlich zwei Ansätze für die Übertragung von Binärdaten mit einer Message:

·        Die Binärdaten werden im kompakten Binärdatenformt als MIME-Attachment der Message übertragen. Vorteil ist die kompakte Darstellung der Daten. Nachteil ist, dass man der Payload nicht explizit ansieht, dass es ein Attachment zur Message gibt.

·        Die Binärdaten werden beim Erzeugen der Payload beim Sender in ein zeichenketten-basiertes Format umgewandelt und als Content eines Elements der Payload übertragen. Vorteil ist die explizit sichtbare Modellierung der Daten in der Payload. Nachteil ist die speicherintensivere Darstellung der Daten, auf die man in der Regel während der Übertragung – oder während eines Mappings – gar nicht zugreifen muss.

SOAP Message Transmisstion Optimization Mechanism (kurz: MTOM) ist eine Performance-Optimierung für die Übertragung von Binärdaten über das SOAP-Protokoll, die die Vorteile beider Ansätze verbindet. Statt die Binärdaten in die Payload aufzunehmen, verweist die Anweisung <xop:include> in der Payload über eine GUID auf das MIME-Attachment, das im kompakten Binärdatenformat mit der Message versendet wird.

Der vom World Wide Web Konsortium empfohlene MTOM-Standard geht davon aus, dass die Binärdaten in der Payload als Content von einem Element vom Typ xsd:base64Binary enthalten sind.

Weitere Informationen zu MTOM finden Sie im Internet unter der Adresse http://www.w3.org/TR/soap12-mtom/.

Umsetzung von MTOM in der Web-Service-Laufzeit

Sie können in der Konfiguration der Web-Service-Laufzeit die MTOM-Optimierung (de)aktivieren, und zwar sowohl für Point-to-Point-Verbindungen als auch für eine erweiterte Kommunikation über den Integration Server. Die MTOM-Optimierung lässt sich dabei für folgende Transportwege (de)aktivieren:

      Für Direktverbindungen (Point-to-Point). Hier können Sie für den Sender festlegen, ob eine MTOM-Optimierung stattfinden soll.

      Für die Übertragung einer Message von einem Sender zum Integration Server über den Web-Service-Adapter.

      Für die Übertragung einer Message vom Integration Server zu einem Empfänger über den Web-Service-Adapter. Hier ist der Integration Server der Sender, beim dem die base64Binary-Binärdaten vor dem Senden der Message gemäß MTOM als Attachment ausgelagert werden.

Weitere Informationen: WS-Adapter im Integration Directory konfigurieren.

Was ist nun beim Sender zu tun, damit die Binärdaten MTOM-optimiert übertragen werden? Nichts. Ist die MTOM-Optimierung aktiviert, braucht der Anwendungsentwickler nur die in base64Binarykodierten Binärdaten dem Feld zuzuweisen, das im ES Repository als Element vom Typ xsd:base64Binary modelliert wurde. Die Web-Service-Laufzeit erkennt beim Erstellen der Message automatisch am Typ des Elements, dass die Daten als Attachment ausgelagert werden können. Ob sie ausgelagert werden, hängt von der Größe der Daten ab (wenn die Binärdaten nicht sehr groß sind – wie beispielsweise bei Signaturen – ist es unter Umständen günstiger, die Daten nicht auszulagern).

Umgang mit MTOM in Mapping-Programmen

Bei der Auslagerung der base64Binary-kodierten Binärdaten aus der Payload wird der Binärcontent eines Elements in der Message-Struktur durch die <xop:include>-Anweisung ersetzt. Da dies so nicht in der XML Schema Definition zur Message-Payload modelliert wurde, führt dies zu einem Abbruch des Mapping-Programms, wenn das Mapping-Programm auf den Binärcontent zugreift.

Um einen durch die MTOM-Optimierung ausgelösten Abbruch zu verhindern, haben Sie folgende Möglichkeiten:

      Sie ändern Ihr Mapping-Programm, so dass zukünftig <xop:include>-Anweisungen nicht mehr zum Abbruch führen.

      Sie demarkieren in den Grundeinstellungen des Operation-Mappings das Ankreuzfeld XOP-Inkludierungen nicht auflösen. Dann werden vor der Ausführung der mit dem Operation-Mapping vorkonfigurierten Mapping-Programme alle ausgelagerten Binärdaten wieder base64Binary-kodiert in die Payload übernommen. Wie zeit- und speicherintensiv dies ist hängt von der Größe der Attachments ab.

XSLT-Beispiel

Das folgende Beispiel zeigt, wie Sie ein XSLT-Mapping-Programm anpassen können, das ansonsten bei einer Auslagerung von Binärdaten als Attachment auf Grund der MTOM-Optimierung abbrechen würde. Zur Vereinfachung geht das Beispiel von folgender Payload aus:

Beispiel-Payload vor und nach der MTOM-Optimierung

(1) Vor MTOM-Optimierung

(2) Nach MTOM-Optimierung

<?xml version="1.0"
   encoding="utf-8"?>

<ROOT>xxxbinxxxbase64xxx</ROOT>

<?xml version="1.0"
   encoding="utf-8"?>

<ROOT>
 <xop:include
  xmlns:xop="http://www.w3.org/2004/08/xop/include"
  href="cid:00132120D4961DDBB695E429DA7E583C@sap.com">
</ROOT>

Das folgende XSLT-Programm greift mit dem XSLT-Element <xsl:value-of> direkt auf den Content des Elements <ROOT> zu. Da dieser Content nach der MTOM-Optimierung durch das Element <xop:include> ersetzt worden ist, führt <xsl:value-of> zu einem Fehler:

<xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:output method="xml" indent="no" />

    <xsl:template match="/">
       <ROOT><xsl:value-of select="/ROOT"/></ROOT>
    </xsl:template>

</xsl:transform>

Diesen Fehler kann man dadurch vermeiden, indem man nicht auf den Content von <ROOT>zugreift, sondern <ROOT> mit seinem Content kopiert, wie in dem folgenden XSLT-Programm:

<xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:output method="xml" indent="no" />

    <xsl:template match="/">
       <xsl:copy-of select="/ROOT"/>
    </xsl:template>

</xsl:transform>

Wenn die Ausgangsstruktur überhaupt keine Elemente vom Typ xsd:base64Binary hätte, würde eine aktivierte MTOM-Optimierung ebenso zu keinem Abbruch führen.

Zugriff auf Attachments in Mapping-Programmen

Mapping-Programme werden auf der Java-Seite des SAP NetWeaver AS ausgeführt. Die Mapping-Laufzeit überträgt daher die Message-Payload vor der Mapping-Programm-Ausführung von der ABAP-Seite des Application Servers zur Java-Seite. Da auf die MIME-Attachments der Message in der Regel in Mapping-Programmen nicht zugegriffen wird, überträgt die Mapping-Laufzeit in der Voreinstellung nur die Payload und nicht die Attachments. Dies gilt sowohl für Attachments, die auf Grund der MTOM-Optimierung der Web-Services-Laufzeit ausgelagert werden, als auch für Attachments, die ein Sender unter Verwendung der XI-Laufzeit über Proxy-Methoden zusammen mit einer Payload sendet.

Wenn Sie von einem Mapping-Programm auf ein Attachment zugreifen wollen, muss es vor der Ausführung von der ABAP-Seite auf die Java-Seite übertragen werden. In den Grundeinstellungen des Operation-Mappings, in dem Sie auf das Mapping-Programm verweisen, können Sie diese Übertragung konfigurieren (setzen Sie dazu das Ankreuzfeld Attachments lesen).

Um in einem Mapping-Programm auf Attachments zugreifen zu können, bietet die Mapping-API entsprechende Klassen un Methoden an. Im einzelnen funktioniert der Zugriff folgendermaßen:

      Zugriff auf Attachments in Message-Mappings

Wenn Sie im Message-Mapping auf ein in der Ausgangsstruktur modelliertes Attachment zugreifen müssen, haben Sie folgende Optionen:

¡        Sie definieren eine benutzerdefinierte Funktion und greifen über Methoden der Mapping-API auf das Attachment zu. Sie können auf das Attachment als Byte-Array zugreifen (über die Methode getContent() des Interface Attachment) oder als base64Binary-kodierter String (über die Methode getBase64EncodedContent() des Interface Attachment).

¡        Sie greifen im Message-Mapping über eine Funktion auf ein Attachment zu. Dies ist dann der Fall, wenn Sie den Inhalt eines Elements, das den Typ xsd:base64Binary hat, als Eingangsparameter für eine Funktion im Datenfluss-Editor modellieren. Die Mapping-Laufzeit übergibt das Attachment an die Eingangs-Queue der Funktion als base64Binary-kodierten String, und zwar selbst dann, wenn das Attachment auf Grund der MTOM-Optimierung ausgelagert worden ist.

      Zugriff auf Attachments in Java-Mappings

In Java-Mapping-Programmen können Sie direkt die Klassen und Methoden der Mapping-API für den Zugriff auf Attachments nutzen.

      Zugriff auf Attachments in XSLT-Mappings

In XSLT-Mapping können Sie generell Java-Methoden aufrufen (weitere Informationen: XSLT Mapping mit Java-Erweiterung), von daher können Sie die gleichen Methoden der Mapping-API für den Zugriff auf Attachments nutzen.

Innerhalb der Mapping-API greifen Sie mit Medhoden des Interface InputAttachments auf Attachments der Ausgangs-Message zu und hängen mit Methoden des Interface OutputAttachments die geänderten Attachments an die Ziel-Message. Weitere Informationen zur Mapping-API finden Sie im SAP Developer Network unter der Adresse https://www.sdn.sap.com/irj/sdn/javadocs (SDN-User nötig).

Weitere Informationen

Binärdaten modellieren (CCTS/frei modelliert)

Operation-Mapping-Grundeinstellungen

 

 

 

 

Ende des Inhaltsbereichs