Specifications

Document specifications describe the internal structure of your document instances. In the previous section, we learned that document definitions reference document specifications in order to provide document validation and mapping capabilities to BizTalk Messaging Services.When a channel initially receives a document, its document definition is queried for (among other things) its document specification.The document specification exists as an extended XDR file, and this file is used to validate the document instance arriving at the channel. XDR stands for "XML Data-Reduced" and is a method for describing the schema (or layout) of an XML document. Use the BizTalk Editor to create new specifications and edit existing document specifications. The editor makes it easy to graphically build and visualize complicated document specifications for various instance document formats, including XML, EDIFACT, X.12, and custom positional or delimited text file formats, although there are some tricks to generating specifications based on flat-file formats.

Figure 4.6 Specifying Document-Level Tracking Options for the Server

Figure 4.6 Specifying Document-Level Tracking Options for the Server

Here are a sample flat-file format representing a simple purchase order, and some tips to using the editor to model this format:

Joe Smith 123 Main Street Somewhere, CA 92121 123-456-7890 20 56789 Apple Pie 9.99

5 23232 Box of plastic forks 2.50

Here are a sample flat-file format representing a simple purchase order, and some tips to using the editor to model this format:

Joe Smith 123 Main Street Somewhere, CA 92121 123-456-7890 20 56789 Apple Pie 9.99

5 23232 Box of plastic forks 2.50

In the preceding code, the individual lines are delimited by carriage returns, while the fields within each line are tab-delimited. The steps to take to model this file in the BizTalk Editor are as follows:

1. Create an XML tree in your specification to look like Figure 4.7. Figure 4.7 Modeling a Flat-File Format in the BizTalk Editor

1. Create an XML tree in your specification to look like Figure 4.7. Figure 4.7 Modeling a Flat-File Format in the BizTalk Editor

2. Select the FlatOrder (root) node in the tree view on the left and the Reference tab on the right, then change the Standard property to CUSTOM. Changing this property is required to parse and validate any non-XML documents.

3. Change the Default Record Delimiter value to CR (0xd).

4. Change the Default Field Delimiter value to TAB (0x9).

5. Next, select the Parse tab on the right pane, and change the Field Order property to Infix.This tells the validator to look for the delimiters between different records or fields, but not before the first field or after the last field.

6. Change the Skip Carriage Return property's value to No.

7. Duplicate these property settings for the Buyer node and the Item node to explicitly set the validation properties for these nodes.

8. Finally, select the Item node and its Reference tab. Change the Maximum Occurrences value from 1 to *.This is necessary to allow multiple items to be ordered in one instance of a document.

The document specification is now complete, and an instance document can be validated from the Tools | Validate instance menu option. Selecting the simple order flat file (Figure 4.7), we see the internal XML representation of the file resulting from BizTalk reading this document instance and parsing and validating it against our newly created document specification.

There is a substantial benefit to separating the document definition from its document specification. The document specification provides abstract information about the types and structures of document instances, while the document definition provides specific information about the document instance. One of the benefits lies in the ability to have multiple document definitions that reference the same document specification.This might be necessary if you sometimes need to enable global tracking fields, but not always. For example, the specification contains metadata information about the document standard (i.e., XML, EDIFACT, etc.), document type, and version, in addition to the document schema information inherent in an XDR schema. Furthermore, a simple built-in versioning mechanism is provided here, since the document specification is imported into the internal configuration database whenever you create a document definition. For example, you reference a version of a specification in a document definition and use that definition to execute your business rules. Several weeks later, you update the specification to accommodate a slightly different schema based on requirements from a new business partner, and then you create another document definition to reference the revised specification. Even when the underlying original specification file changes, your original document definition remains valid. This allows you to accommodate different versions of a document specification, each of them actively participating in your business practices at any given time.

Note_

Sometimes the term "BizTalk Independent Document Specification" is used in information describing BizTalk. This term is more accurately the "BizTalk Framework," since it describes the internal, SOAP-based formatting of BizTalk documents in transit. "Document specifications," as we're discussing, are concerned with the body of the internal SOAP message, which represents our original business document.

Was this article helpful?

0 0

Post a comment