[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ]

This defines the “Outbound Document Definition”. In other words, this is the document format we expect to be delivered to the Port. Since the Outbound Document (our “Purchase Order Bid”) is different from the “Inbound Document” (West Wind’s “Store Order” format), the incoming document needs to be converted. Using BizTalk terminology, we say it has to be “mapped”. Documents are mapped through Maps (who would have guessed so?). I will describe Maps in detail a little later in this article. For now, we simply select the appropriate map (yes, I know you don’t have the map yet, but just hang with me here for a second…).

Now imagine we want to start doing business with another organization. We already have all the Ports and Document Definitions in place to accept orders, but the new business partner may use yet another document format. No problem! We simply attach another Channel to the existing Port, specify the Map to convert the document formats and we are ready to go. This is a purely administrative task that can be performed in a matter of minutes (well, complex Maps may take you a little longer, but you get the point…). As you can see, Port/ Channel pairs provide you with a very flexible mechanism to set up new relationships without producing more source code.

Just like we can create Ports to Applications, we can also create Channels from Applications. The approval notice that needs to be sent is a good example. We need our order processing back-end to initiate the approval message, so we create a Channel from that Application and link it to the “Send Approval” Port. The process is very similar to creating a Channel from an Organization with the exception that you specify an Application as the source, rather than an Organization.


Applications in the BizTalk sense are a very confusing subject, mainly because they are so simple, it’s hard to believe. Don’t think of an Application as a program, component or any other kind of compiled code. Think of an Application is a set of Transactions that are logically connected. An Application in the BizTalk sense could be the order system we build in the examples described in this document. All the messages and transactions fitting into the order entry schema are part of that Application. This is conform to the term “COM+ Application” that simply defines a number of related COM+ Components and attaches a name to them.

Applications are defined in the Organization definition for the Home Organization (other Organizations do not have attached Applications!). To create a new Application, simply click the “New” button in the “Applications” page, specify a name, and you are all done. There isn’t any more to it.

“So what are Applications for?” you ask. Well, there are a couple of reasons why you would want to categorize messages. Document tracking for instance.

Document Definitions

Document Definitions are another important building block for BizTalk systems. All messages routed through BizTalk have to be defined so BizTalk Server can handle them appropriately. Document Definitions are defined using XML Schemas. Document Definitions can be very simple specifying only a couple of fields in a document, or they can be very complex defining field types and lengths and even BizTalk routing information.

Microsoft BizTalk Server 2000 provides a tool to create Document Definitions: The Document Editor.

Document Editor

The BizTalk Document Editor is basically a Schema Editor with some special features for BizTalk:

When you create a new document, the Document Editor allows you to base the new document on a template, or to start with a blank document. You can then proceed to add new “Records” and “Fields”. By default, records are the equivalent of tags and fields equate to attributes. But you can change that and actually turn a field into a tag by changing the “Type” setting in the “Declaration” page. The major difference between records and fields is that records can have sub-records and fields as child items, fields cannot.

The editor basically allows you all the freedom XML Schemas provide. You can set the data type, valid values, minimum and maximum content length, default values, you can specify whether or not a field or record is optional or required, you can specify the number of times a tag can occur, and so forth.

In addition, the Document Editor can handle BizTalk specific settings such as routing information. The following image shows the definition of routing fields for a self-routing document (see below for more information on self-routing documents):

[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ]