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 ...)
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