XML —

BizTalk Document Header

A BizTalk document is a well-formed XML document, so the BizTalk document header contains standard XML header information, such as the XML version and the language. A typical BizTalk document that does not contain any content would look as follows:

  <SOAP-ENV:Envelope
     xmlns:xsi= "http://www.w3.org/1999/XMLSchema/instance"
     xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope"
     xsi:schemaLocation=
     "http://www.northwindtraders.com/schemas/NPOSchema.xsd">
     <SOAP-ENV:Header xsi:type="NorthwindHeader">
     <!--BizTags begin here -->
        <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:type/of/agreement">
              </dlv:address>
           </dlv:to>
           <dlv:from>
              <dlv:address xsi:type="agr:type/of/agreement">
              </dlv:address>
           </dlv:from>
           <dlv:reliability>
              <dlv:confirmTo>www.uri.where.to.send.confirmation
              </dlv:confirmTo>
              <dlv:receiptRequiredBy>
                 2300-05-44T03:00:00+09:00
              </dlv:receiptRequiredBy>
           </dlv:reliability>
        </dlv:delivery>
        <prop:properties SOAP-ENV:mustUnderstand="1"
        xmlns:prop="http://schema.biztalk.org/btf-2-0/properties">
           <prop:identity>uuid:00000000-0000-0000-0000-00000000001
           </prop:identity>
           <prop:sentAt>2300-05-14T03:00:00+09:00</prop:sentAt>
           <prop:expiresAt>2300-05-44T03:00:00+09:00
           </prop:expiresAt>
           <prop:topic>uri/topic</prop:topic>
        </prop:properties>
        <fst:manifest xmlns:fst=
           "http://schema.biztalk.org/btf-2-0/manifest">
        <fst:reference fst:uri="uri/to/reference">
           <fst:description>text description of document element
           </fst:description>
        </fst:reference>
        </fst:manifest>
        <prc:process SOAP-ENV:mustUnderstand="1"
           xmlns:prc="http://schema.biztalk.org/btf-2-0/process/">
           <prc:type>uri/type/of/business/process</prc:type>
           <prc:instance>uri/unique/identifier/of/process
           </prc:instance>
           <prc:handle>uri/with/additional/information</prc:handle>
        </prc:process>
     <!--BizTags end here -->
     </SOAP-ENV:Header>
     <SOAP-ENV:Body xsi:type="NorthwindBody">
        <!-SOAP document enclosed ends here -->
     </SOAP-ENV:Body>
  </SOAP-ENV:Envelope>

Because delivery and properties are mandatory header elements and the process element must be interpreted when included, the SOAP-ENV:mustunderstand property for these elements must be set equal to 1 so that the receiving BFC server knows the sections contained within these elements must be understood to process the document.

The following code shows an example DTD for a BizTalk document.

  <!ELEMENT SOAP-ENV:Envelope  (SOAP-ENV:Header )>
  <!ATTLIST SOAP-ENV:Envelope  xmlns:xsi      CDATA  #REQUIRED
                               xmlns:SOAP-ENV CDATA  #REQUIRED >
  <!ELEMENT SOAP-ENV:Header  (dlv:delivery , prop:properties ,
                              fst:manifest , prc:process )>
  <!ATTLIST SOAP-ENV:Header  xsi:type CDATA  #REQUIRED >
  <!ELEMENT dlv:delivery  (dlv:to , dlv:from , dlv:reliability )>
  <!ATTLIST dlv:delivery  xmlns:dlv               CDATA  #REQUIRED
                          xmlns:agr               CDATA  #REQUIRED
                          SOAP-ENV:mustUnderstand CDATA  #REQUIRED>
  <!ELEMENT dlv:to  (dlv:address )>
  <!ELEMENT dlv:address EMPTY>
  <!ATTLIST dlv:address  xsi:type CDATA  #IMPLIED >
  <!ELEMENT dlv:from  (dlv:address )>
  <!ELEMENT dlv:reliability  (dlv:confirmTo ,
                              dlv:receiptRequiredBy )>
  <!ELEMENT dlv:confirmTo  (#PCDATA )>
  <!ELEMENT dlv:receiptRequiredBy  (#PCDATA )>
  <!ELEMENT prop:properties  (prop:identity , prop:sentAt ,
                              prop:expiresAt , prop:topic )>
  <!ATTLIST prop:properties xmlns:prop              CDATA #REQUIRED
                            SOAP-ENV:mustUnderstand CDATA #REQUIRED>
  <!ELEMENT prop:identity  (#PCDATA )>
  <!ELEMENT prop:sentAt  (#PCDATA )>
  <!ELEMENT prop:expiresAt  (#PCDATA )>
  <!ELEMENT prop:topic  (#PCDATA )>
  <!ELEMENT fst:manifest  (fst:reference )>
  <!ATTLIST fst:manifest  xmlns:fst CDATA  #REQUIRED >
  <!ELEMENT fst:reference  (fst:description )>
  <!ATTLIST fst:reference  fst:uri CDATA  #REQUIRED >
  <!ELEMENT fst:description  (#PCDATA )>
  <!ELEMENT prc:process  (prc:type , prc:instance , prc:handle )>
  <!ATTLIST prc:process  xmlns:prc               CDATA  #REQUIRED
                         SOAP-ENV:mustUnderstand CDATA  #REQUIRED >
  <!ELEMENT prc:type  (#PCDATA )>
  <!ELEMENT prc:instance  (#PCDATA )>
  <!ELEMENT prc:handle  (#PCDATA )>

As you can see in the previous two code samples, a BizTalk document consists of four major sections designated by the delivery, properties, manifest, and process elements. Let's look at these elements in the following sections in detail.

Loosely Coupled Messages

As mentioned, the BizTalk header contains only information about the destination and source BizTalk servers. There is no information within the BizTalk document header that identifies what method or object will use this information. In other words, the BizTalk document header has no real information about the application that will process it.

It's up to the receiving BizTalk server to identify the incoming message and route it to the correct application. For example, a BizTalk server can be set up so that all messages coming from http://www.northwindtraders.com with an identity that begins with PO00123 will be passed to the new order processing object. (Identity is a child element of the properties element that will be discussed in detail later in this chapter.) The same message sent to a different company may be sent to a completely different component. These messages are called loosely coupled, meaning that they are not coupled with specific processing applications.