Planning to Use the Tracking System

At this point, you have gained an understanding of how the BizTalk Document Tracking System operates. The next step is to prepare for using it in a real-world system. This section presents some common usage scenarios for the document tracking system. You will learn that document tracking can fulfill some critical system requirements, such as record keeping, analysis, and even data recovery. On the other hand, you must also understand the impact of document tracking on system performance and scalability. We will discuss these issues and present some important information regarding document size constraints in the tracking system. Finally, we will reveal some steps that you can take when designing document specifications to facilitate field-level tracking of instance documents.

Usage Scenarios for Document Tracking

The BizTalk Server Document Tracking System is an invaluable tool for both developers and managers. Developers appreciate the value of document tracking for testing and debugging. Managers appreciate the tracking system because it often satisfies important business requirements for record keeping and auditing. The tracking system can help to resolve customer inquiries or disputes regarding “missing” documents. You can use the tracking system to satisfy contractual requirements, which may stipulate that copies of all transmitted data must be kept in an archive.

The tracking database can also be used to help analyze your business. For example, if your system is responsible for sending invoices, you can configure BizTalk Server to store the amount of each invoice transmitted to a customer. Armed with this information, you can write queries and build reports that calculate the total monetary value of invoices sent in a given time period to each customer.

There are also some less obvious ways to leverage document tracking. For instance, BizTalk Server allows you to submit documents programmatically using the IInterchange::Submit() API. When you submit documents in this fashion, there is no way for BizTalk Server to send the caller a response document, even if the caller explicitly requests a response. The good news is that a response document is actually generated and saved to the tracking database—it's just not delivered to the caller. You can save the submission handle returned by the call to IInterchange::Submit() and then use this handle to query the tracking database for the response document. This process can easily be automated by passing the submission handle to the API exposed by the tracking system.

The Effects of Tracking on Scalability and Performance

The critical factor in determining whether your system can take advantage of BizTalk Document Tracking is the anticipated size of documents to be processed by the server. Microsoft has stated that the maximum supported size of a document during any portion of an interchange is 20 MB. This is the threshold for BizTalk Server Document Tracking. If you anticipate having to process documents that exceed this size constraint, then you should disable document tracking in the server group properties.

Provided that your document sizes fall within the acceptable range, take steps to ensure that the tracking system does not become the major bottleneck of your system. Install the tracking database on a separate server from your other BizTalk databases and make sure that there is adequate disk space. You should also have an archiving strategy for the tracking database. Depending on the expected volume of interchanges, plan to move data from the primary tracking database to a permanent archive on a regular basis. Tracking database maintenance is discussed in “Maintaining the Tracking Database” later in this chapter.

Preparing BizTalk Specifications for Tracking

One of the first development tasks in a BizTalk Server system implementation is to define specifications for all documents that will pass through BizTalk Server. The vocabulary for these specifications is a superset of Microsoft's XML Data Reduced (XDR) schema dialect. From a programming perspective, an attractive feature of the XDR vocabulary is its capability to associate data types with elements and attributes. Disciplined programmers are well aware of the importance of strong data typing. Data type enforcement helps catch erroneous data and allows compilers to allocate the appropriate amount of memory for data. As it turns out, specifying data types in BizTalk document specifications is equally important to the document tracking system.

It is easy to understand why the document tracking system requires knowledge of data types. Tracking data is stored in an SQL Server database, and all fields in an SQL database expect a specific data type. When you assign a data type to a value in a BizTalk specification, the tracking engine can store that value in the proper database field.

Of course it is possible to convert a value found in a BizTalk document to a generic data type such as a string value. In fact, this is what happens in the tracking system when you do not specify data types in a specification. Typeless data selected for tracking is merged into an XML text field, which you must parse to extract a single field.

For each specification, BizTalk Server allows you to select up to two fields of the same data type for tracking in a strongly typed fashion. Additional fields of the same data type must be tracked together in an XML tree. Nevertheless, the specification writer may not know in advance which records will be tracked, so it is a good idea to specify data types for all fields in a specification.

The limitation of two fields per data type is a design choice based on the fact that a database field must be reserved for each strongly typed value. The tracking database reserves two fields per data type. Allowing more than two values of the same data type would require more database fields, which could be wasteful in terms of space.

Another limitation of strongly typed tracking is that the BizTalk Editor does not allow you to set data types on records (elements). You can only assign data types to fields (attributes). If you use the ActiveX Data Objects (ADO) library or SQL Server 2000 to turn recordsets into XML, fields are converted to attributes by default. Thankfully, you can strongly type these attributes using the BizTalk Editor.