POP3 adapter in BizTalk 2006
I've been doing some work recently with the POP3 adapter.
This is a very useful adapter and I find myselft using it in many places.
In fact I always thought it was weird one was not shipped with BizTalk 2004. luckily at the time GotDotNet came to the rescue.
Now it BizTalk 2006 we get a fuller, more tightly integrated, adapter which is great.
I found that there are a few things worth noting though. -
The adapter has a built in MIME decoder. This is a bit of a duplication on the MIME decoder pipeline component, and consideration should be taken as to what to implement where.
The settings in a receive location using the adapter lets you decide if you want to apply MIME decoding in the adapter or not.
If you choose to do so you can then either ask the adapter to treat a specific part of the email as the email body (part 1 being the email body and any attachments are additional parts) or, and this is a real gem - you can specify a content type to pick up.
If you do this, the adapter will look at the list of parts and pick up the first one with the specified content type.
Both options are very useful but should be handled with care.
In many cases, especially when using email client to create MIME messages, it is hard to predict the order in which the attachments will appear in the message. At least from my experience. This makes specifying the part number to use potentially risky.
Same applies to the content type feature, as you will not be sure which attachment will appear first in the message. If you know you only have one xml attachments (and the rest are…say…images) then this is great. If you may have more then one xml attachment you may be in trouble.
A second nice feature of the adapter, which is MIME related, is the ability to decrypt the message. But again - attention should be paid to the following quote from the BizTalk 2006 help file - "Encrypted Messages Received by the POP3 Adapter that are sent to the Suspended Queue may be Viewable in Clear Text"
If you decrypt the message in the adapter and the message gets suspended for any reason, it will be stored in clear text. Now it really depends how much you trust your operations guys…(and girls)
Attention should also be paid to having the correct certificates in the correct store. As usual.
All this said it is nice that adapter actually allows you to disable the MIME decoding feature.
This means that the adapter will pass the whole email message, MIME structure and all to the pipeline. There you can either use the existing MIME decoder or any custom code you require to process it correctly.
In my recent implementation of the adapter we actually needed to receive emails with several attachments in each, but instead of treating this as a multi-part message we needed to extract the attachments and treat each attachment as an independent message.
We've considered two alternatives - one is indeed disabling the MIME decoding in the adapter and developing a custom disassembler that will read the stream and break the MIME message to its part passing back to the pipeline all the messages.
The second approach was to let the adapter decode the message and pass in a multi-part message. Then still have a custom disassembler, but instead of knowing all about MIME processing etc. all the disassembler needs to do is loop on the message parts and form a message from each part.
Both disassemblers would need to call any payload disassembler such as the XmlDisassembler to process the message, perform property promotion etc.
I think it's quite obvious what we chose (well. Ok. The 2nd option, if it wasn't obvious). Main reason was that although we expect a minor hit in performance, the code is so much simpler and there for safer to implement and maintain.