HTTP-Tutorial - Multipart
In unseren bisherigen Beispielen haben wir mit der POST-Methode diverse Inhalte wie XML oder JSON verwendet, welche direkt in den Body der Nachricht übergeben werden. Besteht die Anforderung mehrere, verschiedenartige Inhalte zu übertragen, so scheitern wir mit dieser Methode und es bleibt nur die Option mehrere, einzelne Nachrichten zu übermitteln.
Um das zu vermeiden, kommt hier Multipart ins Spiel. Beim Versand von E-Mail-Nachrichten mit Anhang kommt das Prinzip Multipart zum Einsatz. Daher ist das Verfahren im RFC für Mail spezifiziert (https://datatracker.ietf.org/doc/html/rfc2046). Im Folgenden finden Sie eine beispielhafte Multipart-Nachricht.
POST /someUrl HTTP/1.1Host: localhostContent-Type: multipart/form-data; boundary=2a8ae6ad-f4ad-4d9a-a92c-6d217011fe0fContent-Length: 398--2a8ae6ad-f4ad-4d9a-a92c-6d217011fe0fContent-Disposition: form-data; name="datafile1"; filename="file1.xml"Content-Type: application/xml<file><someData>foo</someData></file>--2a8ae6ad-f4ad-4d9a-a92c-6d217011fe0fContent-Disposition: form-data; name="datafile2"; filename="file2.json"Content-Type: application/json{'report': {'someOtherData':'bar'}}--2a8ae6ad-f4ad-4d9a-a92c-6d217011fe0f--Eine Multipart-HTTP-Nachricht besteht aus einem (globalen) Headerteil am Anfang, gefolgt vom Body. Dieser ist wiederum in Teil-Segmente unterteilt, die jeweils eine eigene Header-Sektion haben können. Die Teilsegmente werden über eine vorgestellte sogenannte Boundary (Teiler) mit einem doppelten Bindestrich (–) gekennzeichnet. Definiert wird die Boundary im globalen HTTP-Header Content-Type. Dort kann auch mit dem MIME-Type multipart/form-data definiert werden, dass es sich um eine mehrteilige Nachricht handelt.
Nach dem ersten Boundary-Token folgt das erste Segment. Dieses hat selbst einen eigenen Header-Bereich. Mittels Content-Disposition kann man durch den Attributnamen der Sektion eine eigene ID vergeben und zudem noch den Dateinamen, falls der Teil lokal gespeichert werden muss. Der Content-Type gibt Auskunft über die Art des Inhalts.
Multipart via Phase 1 - HTTP
Ein Client sendet eine Nachricht, welche aus einem XML- und einem JSON-Teil besteht. Ein Bestandteil könnte auch eine binäre Datei sein, wie eine PDF-Datei, eine Bild-Datei oder eine XML-Datei mit den zugehörigen Metadaten.
Die Nachricht wird nun an ein Profil mit einem HTTP-Eingangsagenten gesendet. Ein Teilsegment hat im eigenen Header das name-Attribut, um die Sektion eindeutig zu identifizieren. Um mit einem eventbasierten HTTP-Profil eine Sektion für die Verarbeitung zu erhalten, geben Sie im Feld Multipart FileKey den Wert des Attributs an. In dieser Beispielsdatei hier, handelt es sich in der zweiten Sektion um datafile2.
Multipart via Phase 6 - HTTP
Daten aus dem Profillauf können als Multipart-Nachricht versendet werden. Allerdings gibt es hier eine kleine Einschränkung, dass ein Multipart nur mit einem (beliebig wählbaren) Mime-Type versendet werden kann, alle anderen sind reiner Text. Durch das Setzen der Checkbox Multipart/Form-Data wird ein zusätzliches Feld Dateiname eingeblendet. Hier können Sie dann den Dateinamen einsetzen.
Der eigentliche Inhalt wird ausschließlich im Feld Query/Body hinterlegt. Dabei wird hier der Key einer Query für das name-Attribut verwendet. Der Value gibt den eigentlichen Payload an. Eine Besonderheit ist hier das Schlüsselwort <http-data>, da es mit dem Inhalt des Mappings ersetzt wird. Für diesen Part gelten der konfigurierte Mime-Type im Antwortweg und der angegebene Dateiname.
WICHTIG: Es ist aktuell nicht möglich, mehr als eine Datei in Phase 6 mittels Multipart zu versenden! Als Workaround können Sie die Dateien als MSG_CALL Variablen an ein Folgeprofil in Phase 1 HTTP Cron weiterleiten und dort mittels Multipart versenden.
Multipart via Phase 1 - HTTP Cron
Der zeitgesteuerte HTTP-Eingangsagent kann ebenfalls Multipart-Nachrichten, sogar mit variablem Inhalt, versenden. Ein Cron-HTTP Multipart kann Content-Type in allen Formaten erzeugen.
