Spent a bit of time recently with the new POP3 adapter for BizTalk, and wanted to share some notes and screenshots.

I currently have a BizTalk solution that I've built on a VM for use in customer demos. I decided to add a POP3 receive location to an existing port to see if I could use the same pipeline and architecture even when receiving email. So, first I added the new receive location ...


Next, I configured the adapter. Few notes. The Apply MIME Decoding is great since you don't have to use a pipeline to split the message up into parts. Also, it throws a bunch of email-related fields into the context properties (see below for a screenshot). In my case, my attachment is a flat file, so I set the content type to be text/plain. I also set the Body Part Index to 2. Why 2? When the email message comes in, we create a multi-part message, with the email body as part 1, and attachment as part 2. If I had left this as 0, then the adapter uses the following algorithm (text pulled from BizTalk 2006 help file ...)

If the Body Part Index is set to 0 and the Body Part Content Type is blank then the following algorithm is used to select the BizTalk message body part:
  • Use the first MIME part with the Content-Description header set to "body".
  • Otherwise use the first MIME part with the Content-Type header set to "text/xml".
  • Otherwise use the first MIME part with the Content-Type header set to "text/plain".
  • Otherwise use the first MIME part with the Content-Type header set to text/
  • Otherwise use the first MIME part.
Otherwise if the Body Part Index is set to 0 and the Body Part Content Type is set then the first body part of the incoming message that matches the specified Body Part Content Type is selected as the BizTalk message body part. If there are no parts with a matching content type then the message is suspended.

Otherwise if the Body Part Index is set to a value greater than 0 and the Body Part Content Type is blank then the body part with the specified index is selected as the BizTalk message body part. If the specified index is greater than the number of body parts then the message is suspended.

Otherwise if the Body Part Index is set to a value greater than 0 and the Body Part Content Type is set then the Body Part Index is only applied to those body parts that match the specified Body Part Content Type and the corresponding body part is selected as the BizTalk message body part. If the specified index is greater than the number of parts with a matching content type then the message is suspended. If there are no parts with a matching content type then the message is suspended.



Got all that? Then you just set all the appropriate security fields based on the type of authentication model (remember that the user name format is different depending on the authentication choice). Next, I wrote a very simple .NET app that sends an email, plus attachment, to a chosen mailbox.



Here's the cool stuff. The file processed exactly the same as if I had it submitted to the FILE adapter (which was the original means). Batch gets split up into individual records, and pops back out the other side. But, if I set a breakpoint to check my message out that came in from the POP3 adapter, I can see all the unique context properties that travel with my message ...


Also, you'll see that this is a multi-part message. One of the parts is the body of the email, the other, the content of the attachment. Note that if I had chosen to turn Apply MIME Decoding off, then I would have gotten a single-part message, with the whole raw MIME message (headers, body, attachment).



So, POP3 adapter, neat stuff. Great that you don't need yet another pipeline to parse it out, and that i can truly plug in as just another receive location.