BizTalk Messaging Mechanics

BizTalk Messaging requires the configuration of several properties that contain information that helps BizTalk Server process a document that's been submitted to the BizTalk Messaging Engine. This section discusses the new terms and properties encountered when configuring BizTalk Messaging. In particular, we will investigate the following topics:

• Organizations

• Document definitions

• Channels

• Messaging ports

• Envelopes

• Receipts

• Distribution lists

Organizations

BizTalk Server needs to know who to deliver a document to, and the application that receives the document typically insists on knowing who it is from. Therefore, BizTalk Server allows you to create organizations and applications.

An organization can represent a home organization or trading partners. A home organization represents your business, whereas trading partners represent each of the organizations with which you plan to exchange documents.

The diagram shown in Figure 6.2 has one home organization and two separate trading partners. BizTalk Server is responsible for the B2B exchange between the home organization and its trading partners plus the A2A integration of applications in its enterprise. This example depicts a scenario in which Sunset Bank and Federal Central (the “trading partners”) update Big Bank (the “home organization”) with important information about one of Big Bank's clients, Jim Jones. In this case, Jim Jones has withdrawn money from both banks at different times throughout the day, and Big Bank is subsequently notified. In the world of Internet commerce, Jim can view Big Bank's Web Site via his wireless Web browser and see the effects of his transaction in real-time. The internal process involves the integration of the data sent from Big Bank's business partners with Big Bank's own Web Site.

Home Organization

The BizTalk Messaging Manager generates the home organization automatically, and it cannot be deleted. However, you are free to rename the organization and modify its metadata known as identifiers. Identifiers are unique attributes used to assist in defining organizations to a more granular level. For instance, instead of just linking a name to a company, you can also reference a DUNS value, a telephone number, and so on. Each of these can be used to uniquely identify this particular organization within your applications. It is also possible to link applications to your home organization. It is important to understand that applications for internal processing can only be integrated within the home organization. In fact, you will only see the Applications tab when you are defining the home organization—that is, it is not available when defining trading partners.

Other Organizations

Apart from the capability to define application integration within an organization, creating an organization for trading partners is done the same way as defining the home organization. First you define the organization name, plus any comments you might want to add about the organization. All that is left to do is generate any additional identifiers, if required.

Document Definitions

A BizTalk Messaging Manager document definition is a pointer to a specification created by the BizTalk Editor and is referenced inside a channel to represent an inbound or outbound document. The same document specification can be used in any number of channels.

Typically an inbound and an outbound document will not look alike. The inbound document might be a CSV file for instance, and the outbound, an XML file. In cases such as this, you need to incorporate a map into the application (see Chapter 5, “The BizTalk Mapper”).

When creating a document definition in the BizTalk Messaging Manager, you have to give the definition a name. Use something that closely represents the purpose of the exchange and the specification it uses to avoid confusion down the road. After giving the definition a name, you have the option of selecting a document specification. If you choose to use one, then you need to browse its respective WebDAV directory and pick the correct specification.

Other configuration properties to take notice of include the global tracking properties. By choosing particular elements and attributes from a specification, you can track documents processed by BizTalk Messaging Services. Only inbound document fields are tracked by the database. A good example is a purchase order total. By tracking the amount in the <total> element, for example, you can determine the total amount for orders received from a particular trading partner over a certain period of time, or you can calculate the total received from all your business partners in the same amount of time and compare them statistically.

The final set of properties is related to EDI transactions only and is called the selection criteria. Selection criteria are a unique set of name-value pairs that enable BizTalk Server to select a document definition for an inbound X12 or EDIFACT document. Selection criteria are also used to create functional group header information in the envelope of outbound X12 or EDIFACT documents. Again, it is important to remember that the selection criteria features are only available when working with EDI-based documents.

Channels

A channel processes a document based on specific business rules and then passes the parsed document on to a messaging port or distribution list (each discussed later in the chapter). When the BizTalk Messaging Engine receives a document, the first thing it has to do is determine which channel or channels to execute. The engine needs to know the value of three properties to select a channel(s); the inbound document name, source name, and destination name. You can pass this information to the messaging engine in several different ways. It can be passed programmatically using parameters exposed by the IInterchange interface's submit or submitsync methods or by placing the metadata in fields defined in the body of the document, better known as a self-routing document.

These properties give you the capability to specify the channel by name, forcing the engine to execute that channel and only that channel, or to specify by document name, source name, and destination name. If you pass the document, source, and destination data explicitly, the messaging engine selects and executes any channel that fits that combination of criteria possibly causing the execution of multiple channels.

Channels can be defined to receive documents from a single source or declared as open. Open-source channels give you the ability to define a single channel that can accept the same document from multiple sources and then have the messaging engine deliver it to a single destination. You still need to specify a source at runtime either explicitly or in the document itself; however, the channel selection process will select an open channel based on the match of only two properties—the document type and destination—as opposed to all three. It is also possible to create more than one channel for each individual messaging port or distribution list causing the submission of multiple documents to be routed to a single destination.

A channel gives you the ability to customize the processing of your inbound document by setting multiple properties either programmatically (see Chapter 19) or by using the BizTalk Messaging Manager. The following sections discuss several of the properties and their designated tasks. Chapter 7 discusses how to use the BizTalk Messaging Manager wizards to define the values of the properties.

Source Organization or Application

The preceding paragraphs discussed the source property extensively. When defining a channel, your first task is to specify the source of the incoming document. A source can be defined as an organization—that is, a business partner—an internal application, or as open.

It is also possible to assign a BizTalk Orchestration XLANG schedule as the source for your channel, allowing you to integrate the BizTalk Messaging Services with BizTalk Orchestration (see Chapter 16, “Correlation—Integrating BizTalk Server Messaging and Orchestration Services”).

Apart from the BizTalk Messaging Manager, you can explicitly declare the source inside the document itself or within parameters supplied by the IInterchange interface methods.

Just remember that a channel is always created for a messaging port or a distribution list. The destination for the documents that you receive from the source of a channel is designated in the messaging port, or in the messaging ports of the distribution list, for which the channel is created and bound.

Inbound and Outbound Document Definitions

The next step is to specify inbound and outbound document definitions. If you recall, specification development was discussed in Chapter 4. Well, here is where we begin to integrate those specifications into BizTalk Messaging. The inbound document definition represents an incoming document from the source organization or application (or XLANG schedule). The outbound document definition represents the semantic format required by the receiving entity—that is, the destination, which can either be a business partner or an application (or an XLANG schedule). If the inbound document is formatted differently than the specified outbound document, you must specify a map for the channel to transform the inbound document into the outbound document.

Mapping

A BizTalk map uses XSLT to transform documents from one format to another. Maps are created using the BizTalk Mapper, discussed in Chapter 5. The BizTalk Server Messaging Engine uses BizTalk maps to transform the inbound document into the required outbound document format.

As stated earlier, it is possible to generate more than one channel for each messaging port or distribution list. For example, imagine that your organization receives financial data from ATM transactions that occur at two banks. When one of your clients uses either bank's ATM machine, the transaction is submitted via the Web to your application, thereby subtracting the amount from the client's existing bank account. In this case, you will have a channel for each bank, tied to a single messaging port. This gives you the flexibility to map two distinct inbound document formats, one for each bank, into a single outbound format by defining a different map for each channel bound to the destination port. In fact, for each additional bank you decide to accept transactions from, you simply need to create a channel for them and add that to the existing messaging port.

Tracking and Filtering properties

An interesting feature of the BizTalk Messaging Engine is its capability to track and log individual document fields to a SQL Server tracking database. This feature is only available for inbound documents. The fields are selected per inbound document/channel and are logged each time a document is processed by the channel. This data is easily accessible via a Web-based tracking interface provided out of the box or via custom queries to the SQL Server tracking database (see Chapter 8, “Document Tracking”).

Another feature, known as a channel filtering expression, provides an additional way to define which channel(s) will be invoked when a document is received. When the server processes a document, the value of each of the specified fields is evaluated against the value of the channel filtering expression. If the expression is found to be true, the channel is invoked. If the expression is found to be false, the channel is not invoked. For example, if the channel filtering expression is created to look for a transaction of $500.00 or more, and the transaction is for a withdrawal of $550.00, the channel is invoked.

Document logging properties

BizTalk Server also gives you the capability to store a complete copy of the inbound or outbound documents. These documents can be stored in their native format, their XML format, or both.

Other properties

Other properties that you can set within a channel include

• Configure receipts—You can request a receipt from the destination for a document that you send, and you can generate a receipt to the source for a document that you receive.

• Configure security properties—You can specify that the server verify the encryption and signature for an inbound document, or digitally sign the outbound document.

• Configure advanced properties—You can specify a group control number for documents with EDI formats, set the number and time interval that the server uses to resend documents, and override the transport component and envelope properties for the messaging port or distribution list.

Messaging Ports

Messaging ports are used to define a document's destination and consist of properties used to configure the BizTalk Messaging Engine to efficiently transport business documents to a specified destination via a designated transport protocol. A port must be bound to at least one channel and may be bound to multiple channels.

A messaging port consists of the following metadata:

• Destination

• Transport properties

• Envelope information

• Security properties

When you're designing a BizTalk Messaging architecture, an important thing to consider is the type of transaction you're going to implement (see Table 6.1). Is it an application-to-application integration task, for example, where you are trying to integrate one or more applications in your organization? Or is it more of a business-to-business type scenario, in which you need to integrate two disparate business applications living in two or more distinct organizations?

Table 6.1. Two Types of Messaging Ports

To an Application
EAI/A2A (Application-to-Application)	Designate either an XLANG schedule or an application of the home organization as the destination.
B2B (Business-to-Business)	Either designate a specific trading partner or declare an open destination.

After you decide on the type of application you are going to build, it makes it much simpler to choose the appropriate destination for the document and your business scenario.

Destination

A destination is an application or organization that receives and processes the business document. There are three fundamental destination types:

• Destination organizations

• Destination applications

• XLANG schedules

When choosing to port a message to an application, the application must be added to the home organization prior to creating the port. This is as simple as going to the Organizations link in the BizTalk Messaging Manager, finding your home organization, and adding the application's name to the wizard (see Chapter 7).

A messaging port to an organization can designate a destination organization (that is, trading partner), or it can be declared an open messaging port. Open messaging ports are ones in which the destination organization is not known until either the document is processed (that is, the destination is parsed from the message itself) or parameters from the submit or submitSync methods of the IInterchange interface are passed to BizTalk.

You can configure a messaging port for an XLANG schedule in several different ways. For one, you can configure the messaging port to activate a new instance of an XLANG schedule by specifying the path to the XLANG schedule (.skx) file and a reference to a schedule port. In this case, the messaging engine instantiates a new instance of the schedule and then passes the outbound document to the schedule port designated in the messaging port properties.

You can also configure a messaging port to send a document to an active XLANG schedule. In this case, the document is sent to an MSMQ queue monitored by the running XLANG schedule instance. The document must be self-routing (see Chapter 12, “Advanced BizTalk Messaging”) and contain an MSMQ queue name in the transport property. This feature enables developers to take advantage of and integrate BizTalk Orchestration services into their BizTalk Messaging solutions. See Chapters 9, 10, 11, 13 and 16 for additional information on BizTalk Orchestration.

Transport Properties

Think of a transport property as a choice of vehicles to get your document from point A to point B. The transport services available to you are

• Application Integration Component (AIC)

• File

• HTTP

• HTTPS

• Loopback

• Message queuing

• SMTP

All the services have an address to which the document is sent for processing, except the loopback. The loopback transport is a special type of transport service that enables the synchronous return of data to the application from which it originated. The loopback transport is only available from ports bound to channels whose source is an application. The loopback transport is useful in situations that require the transformation of data during processing—for example, an XLANG schedule that requires the transformation of data. In this case, the transformed data is returned synchronously to the sending application, the XLANG schedule instance.

Envelope Information

An envelope provides additional information by adding BizTalk-specific metadata to the business document. The metadata is placed in either the header or the footer of the envelope, thereby making necessary routing information programmatically accessible to BizTalk via APIs or wizard-driven interfaces. The properties you specify in the envelope provide BizTalk's Messaging Engine with the properties it needs to either parse an inbound document or serialize an outbound document.

The BizTalk Messaging Engine natively supports XML documents and can recognize and parse inbound and outbound XML documents without an envelope.

Envelopes can be constructed using six generic formats:

• Reliable

• Custom XML

• ANSI X12

• UN/EDIFACT

• Flat file (i.e. delimited or positional)

• Custom

Reliable formats are those compliant with the BizTalk Framework 2.0 specification. That is to say that it has all the elements required as a BizTalk Framework document to route and parse documents correctly and is in XML format. A custom format, on the other hand, requires a custom parser or serializer to process inbound or outbound envelopes, respectively (see Chapter 18, “Creating Custom Serializers, Parsers, and Functoids”). Processing X12 or EDIFACT envelopes requires the identification of specific delimiters and also an interchange control number. These properties apply only to the envelopes selected for use with that particular messaging port. The delimiters and interchange control number are optional when working with custom formats. The basis for using them or not using them depends on the requirements built-in to your custom parser or serializer. Just remember that the format of an envelope that you select in a messaging port must agree with the format of the outbound document that it contains, and that the format of the outbound document is determined by the specification referred to in the outbound document definition of a channel. For example, if you choose an envelope with an EDI format for a messaging port, when you create a channel for that messaging port, you must select an outbound document definition that points to a specification that also has an EDI format.

Envelopes for Inbound Processing

The envelopes that you create to process inbound interchanges do not need to be selected in a messaging port to be used by the server but rather in the messaging channel. That being said, BizTalk Server can process an inbound document in X12 or EDIFACT without using an envelope defined using the BizTalk Messaging Manager. However, processing a flat file document does require the creation of an envelope; and the envelope must point to a local or Web-accessible location for validation of the message. The name of the envelope also is required when the document is submitted to BizTalk. When working with a flat file document, an envelope needs to be created.

Envelopes for Outbound Processing

When creating a messaging port in BizTalk Server 2002, you are given the option of selecting an envelope for the documents that are going to be processed by that port. If you decide to use an envelope, the format of the envelope must match the format of the documents referenced by the envelope itself. For instance, if your business document is in XML format, then you must choose an XML-formatted envelope (if you decide to use one at all).

If you decide to use custom XML as your format of choice for encapsulating your business data and you decide not to specify an envelope for a messaging port, the data will be sent using the reliable format—that is, envelopes compliant with the BizTalk Framework 2.0 specification.

As with inbound processing, the use of a custom format requires the integration of a custom serializer to get the data into your proprietary—or non-standardized—custom format.

Finally, if you are going to select an envelope with an EDI format, you must—as with inbound processing—specify an interchange control number and the required delimiters.

Security Properties

Documents sent to a BizTalk Messaging port can be secured using three techniques:

• Encoding

• Encryption

• Digital signatures

BizTalk Server 2002 supports Multipurpose Internet Mail Extensions (MIME) encoding. Using MIME encoding, a programmer can

• Specify alternate content encoding mechanisms for each body part.

• Relate groups of multiple content parts within a message.

• Use character sets other than US-ASCII character sets in body parts and message header fields.

• Specify the intended disposition of a content part (for example, inline or attachment).

BizTalk Server 2002 also supports Secure Multipurpose Internet Mail Extensions (S/MIME) certificate-based public key encryption. Encryption can be applied to business data that you send to your trading partners. By using an encryption certificate to secure the data, you can ensure that only the intended recipient can access the information.

It is also important to know that BizTalk Server supports Secure Multipurpose Internet Mail Extensions (S/MIME) certificate-based public-key digital signing. Digital signing can be used to ensure the authenticity of the source of data, to ensure that the data has not been modified, and to prevent the source of the data from repudiating the message.

The security properties that you designate for a messaging port apply to all channels associated with that messaging port. If you have documents that need to be secured using a different encryption or that do not need to be encrypted, you need to create a separate messaging port with the appropriate security properties for those documents.

Receipts

Receipts are acknowledgements sent by a recipient back to the originating organization or application, announcing that the interchange has occurred successfully. Ultimately, the goal is to

• Configure a receiving server to generate a receipt and return it to the sender

• Make sure that the sender's application is able to handle the receipt

• Process it correctly

In the end, we have a device for tracking the status of a transaction and making it available for future reference.

There are two ways to process and handle receipts in BizTalk. The one you choose depends on the format that you are using for the business exchange. For exchanges that use the X12, EDIFACT, or custom parser—and require receipts—you can configure BizTalk Messaging Manager to use channels for processing receipts. For exchanges that use the XML parser, however, you have the option of using reliable messaging, which processes receipts automatically and guarantees the reliable delivery of data.

Processing Receipts Using Channels

If you are using X12, EDIFACT, or a custom syntax to format your document, then you can expect to use channel properties to control the processing of your receipts.

To use Messaging Services to send a message to a business partner and receive a verifiable receipt message, you need to create a channel and a messaging port to send a message to the proper destination and generate a specification for the receipt. Keep in mind that you have to set a timeout for the receipt and decide what actions to take when a receipt is not returned in a timely manner—for example, resend the message.

On the destination side, create a channel and messaging port for replying with the receipt prior to building the actual business document-processing page because when you design a messaging port, it will be necessary that you have the receipt information on hand to complete the process.

Processing Receipts Using Reliable Messaging

XML documents can facilitate the process of sending and receiving receipts through the use of reliable messaging. If you remember from the previous section on reliable messaging, all this means is that the messages are BizTalk Framework 2.0-compliant. In the header of the message will be a send-to address, to which a receipt should be submitted. For instance, if I were to send a document to my partner using reliable messaging, I would place a URL in the document header to explain where to send my receipt. This reply-to URL address is required for compliant interchanges.

Distribution Lists

We've discussed sending messages to a single destination, but what if you want to send a single message to multiple destinations? The answer is to use a distribution list. A distribution list is a collection of ports that share the same document types and configuration, thereby simplifying the task of sending several different organizations or applications the same data. Some good examples are price listings, catalog updates, newsletters, and even user guides. By submitting a document to BizTalk Server one time, you can be assured that it will reach each of the predefined organizations or applications safely and securely.

Create a messaging port for each of the business partners or applications that you want to share your data with. Then add these ports to a named distribution list.

It is also possible to add future messaging ports to an existing distribution list, so don't feel as though you have to have all your partners in line, prior to designing your application.

BizTalk Server invokes those channels linked to the distribution list and not those associated with the respective messaging ports. This is why it is necessary to create at least one channel for each distribution list. You will, however, use the destination information in those messaging ports to define where those messages are going.

Just remember that distribution lists allow you to aggregate messaging ports for the exchange of data with multiple organizations and/or applications.