HTTP tutorial - Multipart
In our previous examples, we used the POST method to transfer diverse content such as XML or JSON directly into the body of the message. If there is a requirement to transmit several, different types of content, we fail with this method and the only option left is to transmit several, individual messages.
To avoid this, Multipart comes into play. When sending email messages with attachments, the multipart principle is used. The procedure is specified in the RFC for email (https://datatracker.ietf.org/doc/html/rfc2046).
The following is an example of a multipart message.
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--A multipart HTTP message has the structure consisting of a (global) header section at the beginning followed by the body. This is in turn divided into sub-segments, each of which can have its own header section. The sub-segments are identified by a so-called boundary (divider) with a double hyphen (-). The boundary is defined in the global HTTP header Content-Type. There, you can define that it is a multipart message. ith the MIME type multipart/form-data.
The first boundary token is followed by the first segment. This has its own header area. By means of content-disposition, one can assign an own ID to the section by the attribute name and also the file name if the part has to be stored locally. The content type provides information about the type of content.
Multipart via phase 1 - HTTP
A client sends a message that consists of an XML and a JSON part. A component could also be a binary file, such as a PDF, an image file and an XML with the associated metadata.
The message is now sent to a profile with Input Agent HTTP. A sub-segment has the name attribute in its own header to uniquely identify the section. To obtain a section for processing with an event-based HTTP profile, enter the value of the attribute in the field Multipart file key. In this example file, the second section is datafile2.
Multipart via phase 6 - HTTP
Data from the profile run can be sent as a multipart message. However, there is a small restriction here in that a multipart can only be sent with a MIME type of your choice, all others are pure text. By setting the checkbox Multipart/Form-Data an additional field File name is displayed. You can then enter the file name here.
The actual content is stored exclusively in the Query/Body field. The key of a query is used here for the name attribute. The value specifies the actual payload. A special feature here is the keyword <http-data>, which is replaced with the content of the mapping. The configured MIME type in the Response and the specified file name apply to this part.
IMPORTANT: It is currently not possible to send more than one file in phase 6 using multipart! As a workaround, you can forward the files as MSG_CALL variables to a subsequent profile in Phase 1 HTTP Cron and send them there using Multipart.
Multipart via phase 1 - HTTP cron
The time-driven Input Agent HTTP can also send multipart messages, even with variable content. A cron HTTP multipart can generate content types in all formats.
