Uploading a file as an attachment
To upload a file as an attachment, the client application must support the following tasks:
Create the unique, identifying MIME boundary required by the MIME protocol.
--MIME_boundary_763bc8438bvc34iyc2mcv
Create an HTTP header for the message.
Create a MIME header for the attachment. A MIME header follows each MIME boundary except the last. The following example shows a typical MIME header:
Content-Type: rptdesign
Content-Transfer-Encoding: binary
Content-ID: Forecast.rptdesign
where
Content-Type is the type of file to upload. Content-Type is an optional element.
Content-ID and Content-Transfer-Encoding are required elements. The Content-ID in the MIME header maps to the ContentId element of the UploadFile operation.
Prepare and send the SOAP request. An UploadFile request must include the Content element.
Send the attachment.
End the message with a final MIME boundary followed by a zero (0).
--MIME_boundary_gwt[heqhypodjh;
0
About the HTTP header
A typical HTTP header that contains a MIME boundary looks like the following example:
POST / HTTP/1.1
Host: akiko:9000
Content-Type: multipart/related; boundary=MIME_boundary_763bc8438bvc34iyc2mcv;
type=text/xml; start=<request.xml>
Transfer-Encoding:chunked
MIME-Version:1.0
SOAPAction: ""
EA
where
POST/HTTP/1.1 is a required element that indicates the version of HTTP the message uses.
Host: akiko:9000 is the name and port number of the host machine.
Content-Type: multipart/related is a required element.
boundary=MIME_boundary_763bc8438bvc34iyc2mcv is the MIME boundary.
start=<request.xml> is a required element that refers to the Content-ID in the first MIME heading.
Transfer-Encoding is a required element to inform BIRT iHub that this is a chunked message.
MIME-Version is the version of MIME the message uses.
SOAPAction is a required element that the Actuate Information Delivery API does not use. Represent SOAPAction by a set of quotation marks.
EA is a hexadecimal value that represents the size of the chunk.
The client application creates MIME boundaries randomly to ensure the message’s uniqueness.
Writing the UploadFile request
The UploadFile request follows the first MIME boundary. The following example requests that the Encyclopedia volume upload one version of a file titled Forecast.rptdesign:
<SOAP-ENV:Envelope>
<SOAP-ENV:Header>
<AuthId>8ywJQHtcZreNuzqEUboyrIU=</AuthId>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<UploadFile>
<NewFile>
<Name>Forecast.rptdesign</Name>
<MaxVersions>1</MaxVersions>
</NewFile>
<Content>
<ContentId>Forecast.rptdesign</ContentId>
<ContentType>application/octet-stream</ContentType>
<ContentLength>true</ContentLength>
<ContentEncoding>utf-8</ContentEncoding>
</Content>
</UploadFile>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
5a
--MIME_boundary
Content-Transfer-Encoding:binary
Content-ID:MultiSetTimeSeries.rptdesign
…
--MIME_boundary--
0
The response to an UploadFile request is an identifier for the file or folder.
<SOAP-ENV:Body>
<UploadFileResponse>
<FileId>25</FileId>
</UploadFileResponse>
</SOAP-ENV:Body>.