February 24, 2021
Hot Topics:

You've Got the BizTalk POP3 Adapter

  • By Jeffrey Juday
  • Send Email »
  • More Articles »

We used "Basic" authentication and most of the default settings, so all we needed to enter was a user name, password, and mail server. I'll talk later about the Body Part Index setting.

The POP3 adapter deletes messages from the POP3 mailbox once the message is moved into BizTalk. The POP3 adapter does not use a transaction when it pulls the message into BizTalk. So, the potential exists to receive the same message twice. This is a POP3 limitation and not a BizTalk shortcoming.

Messages emitted from the POP3 adapter can be derived from one of the following parts of an email message:

  • The body of the message
  • A message attachment
  • The header information of a message, including the subject and list of recipients

The Body Part Index controls which message part is emitted. You can access all parts from an Orchestration or a Pipeline. As stated earlier, our solution used a Custom Pipeline Component.

Custom Pipeline Component

A Custom Pipeline Component was a better choice than an Orchestration for the following reasons:

  • The overhead and workflow capabilities of an Orchestration were not required.
  • A pipeline has fewer working parts and dependencies than an Orchestration, thus making deployment and configuration easier.
  • An existing application allowed us to easily customize a Pipeline, adding custom code by simply adding a new assembly.

Understanding that a POP3 BizTalk message is divided into multiple parts was the key to implementing our Pipeline solution. The following code illustrates how you can access each one of the POP3 message parts using functions on the IBaseMessage inteface.

for ( int n=0; n<_bizTalkContext.BizTalkMessage.PartCount; ++n )
   partName = "";
      out partName);

   PipelineChannelTrace.WriteLine("Part index == "
      + n.ToString() + " part name == " + partName);

   part = _bizTalkContext.BizTalkMessage.GetPart(partName);

   part.GetSize(out partSize,out implementedValue);

   PipelineChannelTrace.WriteLine("Part information "
      + part.ContentType          + " IsMutable=="
      + part.IsMutable.ToString() + " size=="
      + partSize.ToString()       + " size implemented?.. "
      + implementedValue.ToString());

   stream = part.GetOriginalDataStream();


The preceding code relies on the code from my "BizTalk Pipeline Dreams, Part I" article. Parts of a message include attachments as well as the message header and body information. As you can see in the code above, ContentType and Size properties allow you to handle binary attachments such as Word or Excel files.

In our solution, some of the information populated by the POP3 adapter was not configured to be a "promoted" field; examples are the "From" and "To" fields. We also needed fields indicating the result of the pattern search. So, in addition to looking for patterns in the message, our Pipeline promoted some of these fields so we could route messages using Filters on BizTalk Send Ports configured with the BizTalk SharePoint Adapter.

The final part of our solution required searching for keyword patterns in the BizTalk message Stream.

Scanning the Message for Patterns

The technique we used to scan the Stream for patterns will be the subject of a future article, so I'll just outline the techniques we used.

We combined RegEx, the Regular Expression class, and string manipulation .NET classes in our message Stream scanning solution. Fortunately, we were dealing with ASCII-based attachments and an ASCII message body. Also fortunate for us, the patterns we were searching were simple regular expressions, such as the word "error."

We recognized that attachments and message body can be large. So rather than copying the data into a string and scanning the string, we copied small parts of the Streamed message into a buffer and scanned the buffer.


Email has been one of the biggest contributors to information worker productivity. The productivity gains have come with a price, though; in particular, information workers increasingly need better tools and techniques for managing their inboxes. We recently built an application from BizTalk and the .NET framework to move integration process log result messages monitoring out of users' inboxes and into a centralized automated process.


About the Author

Jeffrey Juday is a software developer with Crowe Chizek in South Bend, Indiana. He has been developing software with Microsoft tools for more than 12 years in a variety of industries. Jeff currently builds solutions using BizTalk 2004, ASP.NET, SharePoint, and SQL Server 2000. You can reach Jeff at jjuday@crowechizek.com.

Page 2 of 2

This article was originally published on December 5, 2007

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date