BizTalk Adapters: Integrating e-mail processing into enterprise solutions

This article discusses:

BizTalk Business Process Architecture

Build a custom BizTalk solution

Extracting and processing data from e-mail

Create a custom adapter

This article uses the following techniques:

BizTalk Server 2006

Directory

First, there are some background introductions

Building a solution

Business process

Create a custom adapter

The situation described below is a common problem that can be found everywhere. You receive various forms of data, and this data usually triggers some sort of customer service, order fulfillment, or other business process. In general, data is sent in e-mail and may be accompanied by other documents. When you receive an e-mail message, you need to send an automatic reply, and the e-mail message must also be saved to a database or line-of-business (line-of-business, LOB) application. Different data types require different e-mail notifications for the data that is received.

It is not easy to handle various data formats and workflows. Luckily, we can resort to Biztalk®server. In this article, I'm going to design a solution to show how to do this kind of processing. My solution uses BizTalk Server to monitor the specified e-mail account for new messages, trigger the confirmation process when new e-mail messages are received, and then save the entire contents of the e-mail message, including all attachments, to the custom database. It also contains conditional logic that sends notifications based on data from the Claim (a schema created in this example). New features in BizTalk Server 2006, including new POP3 adapters, enhanced SMTP adapters, and variable multi-part mail support, will be integrated with solutions.

If you want to deepen your understanding and understanding of BizTalk, you can refer to Aaron Skonnard's very practical introduction in the November 2005 and December editions of this magazine.

First, there are some background introductions

BizTalk server is an integrated server designed to handle mail. Figure 1 shows a typical message processing process. The message is received by one of the locations that belong to the receive port. A port can have multiple receive locations, and each location always has a single port. Each receive location has a specific configuration that applies to one adapter. For example, a receive location might contain configuration settings for a file adapter, specifying which folder to poll from which type of file (file mask). When the adapter receives a new message, the message moves from the receive location to the receive port and then to the pipeline. A pipeline is a series of components that you want to perform an action on for each message. Typically, a pipeline performs tasks such as decoding, decrypting, validating messages, and generating content in the form of XML.

Typical message flow in Figure 1BizTalk

When the work in the pipeline completes, the message is submitted to the SQL server™ database called MessageBox, which contains information about subscriptions, undeliverable messages and pending messages, message properties, tracking, queues, and other important services provided by BizTalk.

BizTalk is built on the publish/subscribe model. Each message that BizTalk receives is automatically routed to the appropriate subscriber, and the subscriber's subscription settings indicate that all messages from a port are to be received. More complex subscriptions may use values promoted from within the message as criteria to locate a particular type of message.

When a message is published to the MessageBox database, if the message is not a subscriber, it is suspended directly. Most of the pending messages can be recovered manually later for processing.

A subscriber in BizTalk can be either a send port or a business process. The subscription settings for each send port determine what messages will be routed to that port. When the sending port for the message is determined, it is routed through the send pipeline. Typically, the purpose of a send pipeline is to combine messages into appropriate formats, sign and encrypt messages, and so on. The message is piped into the adapter configured on the send port.

A business process represents the business process workflow that is performed when BizTalk receives the appropriate message. When a business process sends a message, those messages are published again to MessageBox to route to a matching send port.

BizTalk comes with more than 25 adapters, covering most of the transport protocols and many common applications, including files, FTP, HTTP, SOAP, SMTP, POP3, sharepoint®, SQL Server, Oracle, SAP, and EDI. Most of these can be used for receive and send ports. For a complete list of available adapters, see your BizTalk documentation.

If there are no built-in adapters that meet your needs, BizTalk also allows you to create custom adapters. Later in this article, you will see how to create a custom adapter.

The new BizTalk Server 2006 POP3 Adapter is responsible for polling messages, parsing messages, and detaching attachments from the specified mailboxes. The adapter then creates a new message that contains multiple components, one of which is specified as the body and the other parts correspond to each attachment.

The body section represents the default part that the engine uses for processing because its type is known to BizTalk. However, BizTalk does not need to understand other parts of the message unless we explicitly declare it. In fact, one of the new features of BizTalk Server 2006 is the ability to declare the body of a partial message at design time, without declaring the number of other parts and their types. This is easy to use without prior knowledge of the number of attachments.