Home > Articles > Software Development & Management

  • Print
  • + Share This
From the author of

BizTalk Documents

We must distinguish between BizTalk Documents and Business Documents. BizTalk Documents are the primary container and Business Documents are the primary payload or "body" in a BizTalk transaction. The high-level nesting of content in a BizTalk Document is as follows:

  • BizTalk Documents contain one or more Business Documents, and zero or more binary file attachments. As noted previously, the BizTalk Framework prescribes the schema of BizTalk Documents, in terms of specifying the set of XML-based BizTags that may envelop Business Documents. BizTalk Documents "wrap" BizTags around the Business Documents and, by means of a "manifest" header tag, point to binary attachments that are transmitted (as Multipurpose Internet Mail Extensions body parts or other mechanisms) in the BizTalk Message envelope.

  • Business Documents contain XML markup tags; textual element, attributes, and values; and (optional) binary body parts. As noted previously, the BizTalk Framework does not prescribe the content or schema of individual XML-formatted Business Documents, which must be defined separately under the relevant application or vertical-market domains.

  • Text and binary element values contain business transaction data, such as the fields of a standard purchase order, invoice, sales forecast, bill of lading, or other business document.

BizTalk Documents embed prescribed markup tags (BizTags) to define this content-nesting hierarchy. BizTags use Simple Object Access Protocol (SOAP) 1.1 conventions, declaring some attributes as in the SOAP "envelope" or SOAP "header." The BizTalk document-type is defined by the following BizTags (per BizTalk's XDR document schema, as discussed previously). The hierarchy of elements and attributes in a SOAP-enveloped BizTalk Document is as follows:

  • BizTalk Document Envelope:

    • Contained in SOAP 1.1 Envelope, which contains one instance of a SOAP 1.1 Header and one of a SOAP 1.1 Body as peer subelements.

    • Includes one instance each of the following mandatory attributes: SOAP namespace declaration, SOAP encoding scheme, and XML Schema type declaration.

    • Contains one instance each of the following mandatory elements: BizTalk Document Header (SOAP 1.1 Header) and BizTalk Document Body (SOAP 1.1 Body).

  • BizTalk Document Header

    • Contained in SOAP 1.1 Header.

    • Includes one instance of the following mandatory attribute: BizTalk namespace declaration.

    • Contains the following elements:

      • Delivery (mandatory): Describes how a BizTalk Document is transmitted, routed, and handled. Includes one instance of BizTalk Framework 2.0 namespace declaration and one each of the following elements:

        • To (mandatory): Address of target application. Includes one instance of Address attribute.

        • From (mandatory): Address of source application. Includes one instance of Address attribute.

        • Reliability (optional): Indicates whether notification of reliable delivery is required. Includes one instance each of the sendReceiptTo and receiptRequiredBy attributes, both of which are mandatory if this element is used.

      • Properties (mandatory): Includes one instance each of the following attributes:

        • Identity (mandatory): Universally unique URI reference that identifies BizTalk Document for purposes of logging, tracking, error-handling, or other document-processing and correlation requirements.

        • SentAt (mandatory): Sending timestamp, reflecting the time at which the properties element was created.

        • ExpiresAt (mandatory): Expiration timestamp of the Document, beyond which point in time the associated BizTalk Document is considered to have expired, and must not be processed by the destination business entity.

        • Topic (mandatory): URI reference that uniquely identifies the overall purpose of the BizTalk Document, which is useful for publish/subscribe routing and for verifying the consistency of the BizTalk Document content with its intent.

      • Manifest (optional): Document catalog that includes references to both the Business Documents carried within the primary BizTalk Document in the BizTalk Message, as well as any additional attachments, such as images or binary data, that may be considered a part of the BizTalk Message. Includes one or more instances of the Reference element, each instance of which includes one instance each of the mandatory URI attribute and optional Description element.

      • Process management (optional): Includes one instance each of the following elements:

        • Type (mandatory): URI reference that signifies the type of business process involved.

        • Instance (mandatory): URI reference that uniquely identifies a specific instance of the business process that this BizTalk Document is associated with.

        • Handle (optional): URI reference that provides further information that may be required to identify a step or an entry point within the business process instance.

      • Receipt (optional): includes one instance of the receivedAt subelement.

  • BizTalk Document Body

    • Contained in SOAP 1.1 Body.

    • Includes mandatory Business Document subelement, which includes optional application-specific Business Document namespace and mandatory application-specific Business Document.

    • Encloses XML tags (not BizTags) associated with the XML schemas of the one or more Business Documents. The Business Document implements an application-specific XML schema associated with its document-type. The Business Document's document-type, schema, and associated XML tag-set would be defined outside the BizTalk Framework—for example, by a vendor consortium associated with the commerce document type or e-commerce application.

The BizTalk Framework takes special care to describe mechanisms for encoding both BizTalk Documents and Business Documents.

Both of these are well-formed XML document-types—per the XML 1.0 standard, which only supports Unicode, US-ASCII, or ISO 8859 text strings for markup and element values. However, BizTalk transactions will often be required to transmit binary and other non-Unicode information, such as computer-application files, raster images, or other strings containing unsupported characters. XML processors would interpret binary information as unsupported characters, triggering processing errors. In order to support transmission of this content, the BizTalk Framework defines two permissible encoding mechanisms: one for inline binary content and the other for separate binary file attachments.

To support transmission of inline binary element-values within a Business Document, the BizTalk Framework specifies "base-64" encoding of this content. The base-64 encoding scheme "hides" binary information from XML processors by representing the information with valid characters supported under XML 1.0. Receiving applications are responsible for decoding binary information, as appropriate. This base-64 encoding scheme has the drawback of increasing the potential message size greatly, increasing the concomitant load on processing, network, and storage capacity throughout the BizTalk implementation. Another drawback is that it may run afoul of some XML processors that have design or platform limitations on the size of documents they can parse and process.

To support the transmission of binary content as separate file attachments in a BizTalk Message, the framework specifies encoding of these attachments as separate MIME body parts. Some protocol-specific BizTalk implementations—such as HTTP and SMTP—may use "multipart" MIME to support transmissions of one or more BizTalk Documents, along with one or more attached non-XML files. Microsoft has promised it will publish detailed protocol-specific implementation details as a follow-up to BizTalk Framework 2.0.

  • + Share This
  • 🔖 Save To Your Account