XML —

The delivery Element

The delivery element is a child element of the SOAP Header element. This element includes information about the message such as the source and destination systems. The delivery element identifies where the message has come from and where it is going and gives routing and other supporting information. This element is required and can appear only once. The delivery element contains three child elements: to, from, and reliability. The to and from elements are required. All three elements can appear only once.

The to and from elements

As mentioned previously, both the to and from elements are child elements of the delivery element. Both of these elements contain one child element: address. The address child element is required and can occur only once. The address child element can specify any business entity, such as a URI or a department or organization name. For the to element, the address element contains the business entity for the receiving BizTalk server. For the from element, the address element contains the business entity for the sending BizTalk server. URIs can include prefixes such as http:// that specify the means of transport for a message. You can include a prefix, or you can leave it out and let the BizTalk server resolve the specific address system. If you omit the prefix, the URI is called a logical identifier.

The address element also has a required xsi:type attribute. This attribute signifies the category of the address and determines the structure of the address content. The following code shows an example of a to element and a from element:

  <dlv:delivery SOAP-ENV:mustUnderstand="1"
  xmlns:dlv="http://schema.biztalk.org/btf-2-0/delivery"
  xmlns:agr="uri/of/agreement">
     <dlv:to>
        <dlv:address xsi:type="agr:URIDestination">
           http://www.northwindtraders.com/PO.asp/Billing
        </dlv:address>
     </dlv:to>
     <dlv:from>
        <dlv:address xsi:type="agr:department">
           Orders
           </dlv:address>
     </dlv:from>
  </dlv:delivery>

This document uses two different types of addresses: the first is a URI and the second is a department type. The BizTalk server can identify these two types of addresses.

The reliability element

The reliability element is optional and contains information that can help guarantee reliable delivery of the BizTalk document. When the reliability element is present, the BizTalk server that receives the message must send a message back to the sending BizTalk server using the URI. This process will be discussed in more detail in the section "Receipt documents" below.

The reliability element has two mandatory elements that can occur only once each: confirmTo and receiptRequiredBy. The confirmTo element contains the URL that specifies the transport address to which the receipt will be sent. The receiptRequiredBy element contains a time instant that specifies the absolute time by which the BizTalk message must be received. The content of this element should be formatted according to the International Standard ISO 8601; refer to http://www.cl.cam.ac.uk/~mgk25/iso-time.html for more information about this standard. All times in the BizTalk header will use the ISO 8601 standard. The following code shows an example of a reliability element:

  <dlv:reliability>
     <dlv:confirmTo>www.northwindtraders.com/poConfirm
     </dlv:confirmTo>
     <dlv:receiptRequiredBy>
        2300-05-44T03:00:00+09:00
     </dlv:receiptRequiredBy>
  </dlv:reliability>

If the receipt is not received within a specified period of time, the sending BFC server can attempt to resend the message. If the recipient BFC server gets the message two or more times, the identity element of the properties element can be used to eliminate duplicates of the same BizTalk document. The sending BFC server can also create a delivery failure report after a certain number of retries or when a receipt has not been received after the first attempt.

There is always a small possibility that a recipient BFC server has actually received the message, but has either failed to generate the return receipt, or the return receipt has been lost. In these cases, a failure report might be generated by the sending BFC server when the message was actually sent.

Receipt documents

The receipt document is a SOAP 1.1 compliant message that must contain at least the receipt and properties elements and an empty body. The receipt is not a BizTalk document because it contains no information in its body. The content of the receipt must identify the BizTalk document being acknowledged. The receipt will contain a timestamp marking the time the BizTalk document was received. In addition, the receipt can contain elements copied directly from the BizTalk document being acknowledged.