9. BizTalk Documents with Attachments

Business processes often require Business Documents to be transmitted together with attachments of various sorts, ranging from facsimile images of legal documents to engineering drawings. The attachments are often in some binary format. This section specifies the following:

• A standard way to associate a primary BizTalk Document with one or more attachments in a multipart MIME structure for transport.
• The relationship between the MIME structure for attachments and the <manifest> header entry in the primary BizTalk Document.

Most Internet transports are capable of transporting MIME encoded content, although some special considerations are required for HTTP as described in the HTTP binding section.

9.1 Multipart MIME Structure

The compound content of a BizTalk Message, consisting of a primary BizTalk Document and one or more attachments, must be carried in a MIME structure that follows the rules for the multipart/ related MIME media type as described in RFC 2387.

The following example shows a BizTalk Document with two attachments that constitutes an automobile insurance claim. The primary BizTalk Document contains the claim data, and is transmitted along with a facsimile image of the signed claim form (Claim.tiff) and a digital photo of the damaged car (Car.jpeg).

MIME-Version:1.0
Content-Type:Multipart/Related;
boundary=biztalk_2_0_related_boundary_example;
type=text/xml;
start="<claim.xml@claiming-it.com>"
Content-Description:Thisistheoptionalmessagedescription.

--biztalk_2_0_related_boundary_example
Content-Type:text/xml;charset=UTF-8
Content-Transfer-Encoding:8bit
Content-ID:<claim.xml@claiming-it.com>

<?xmlversion='1.0'?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header>
<!--deliveryandpropertiesheaderentriesomittedforbrevity-->
<manifestxmlns="http://schemas.biztalk.org/btf-2-0/manifest">
<referenceuri="#insurance_claim_document_id">
<description>InsuranceClaim</description>
</reference>
<referenceuri="CID:claim.tiff@claiming-it.com">
<description>FacsimileofSignedClaimDocument
</description>
</reference>
<referenceuri="CID:car.jpeg@claiming-it.com">
<description>PhotoofDamagedCar</description>
</reference>
</manifest>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<claim:Insurance_Claim_Autoid="insurance_claim_document_id"
xmlns:claim="http://schemas.risky-stuff.com/Auto-Claim">
<!--...claimdetails...-->
</claim:Insurance_Claim_Auto>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

--biztalk_2_0_related_boundary_example
Content-Type:image/tiff
Content-Transfer-Encoding:base64
Content-ID:<claim.tiff@claiming-it.com>

...Base64encodedTIFFimage...

--biztalk_2_0_related_boundary_example
Content-Type:image/jpeg
Content-Transfer-Encoding:binary
Content-ID:<car.jpeg@claiming-it.com>

...RawJPEGimage...

--biztalk_2_0_related_boundary_example--

The rules for the structure of the <attachment> elements describing the attachments in the <manifest> header entry of the primary BizTalk Document are explained in the next section. The rules for the use of the multipart/related media type are given in RFC 2387. The additional rules for the usage of the multipart/related media type in a BizTalk Message with attachments are as follows:

• The primary BizTalk Document is carried in the root part of the multipart/related structure.
• The media type for all BizTalk Documents is text/xml as described in RFC 2376.
• Every part, including the root part, must contain a Content-ID MIME header structured in accordance with RFC 2045.
• In addition to the required parameters for the multipart/related media type, the start parameter (optional in RFC 2387) must always be present.

9.2 Manifest Structure for Attachments

The relationship of the <reference> elements within the <manifest> header entry that denotes MIME part attachments is simple. The uri attribute of such <reference> element contains the location of the associated attachment in the form of the Content-ID URL based on the Content-ID of the MIME part that constitutes the attachment. The URL formed in accordance with RFC 2111 that defines Content-ID URLs.