News

My Stats

  • Posts - 26
  • Comments - 25
  • Trackbacks - 55

Twitter










Recent Comments


Recent Posts


Archives


Post Categories



Recently we have been receiving another series of complaints from clients that had trouble reading the pdf attachment of a BizTalk dynamic generated email. For some years we have been using the MIME encoder pipeline component and dynamically buildup our emails as multi-part message from inside orchestration. We got the mustard from here.

As said, it wasn't the first time we had these complaints. But it was always for a small minority of users only. Hence it sounded more like a user-specific issue. Since the smoke kept coming back I decided to start looking for a small fire at our side. Which I think I found:

By default the MIME encoder pipeline component puts 'text/plain' as the MIME content-type. This will always work if your content is in fact of type 'text', but for all the other types such as a pdf it is not correct in the strict sense.

Success will depend on the mail-client: apparently GMAIL doesn't care that much about it, same story for the majority of our Exchange/Outlook clients. If you want 100% coverage, the only good solution is to specify the correct MIME type for every attachment. For a pdf attachment it should be 'application/pdf':
 



Please note that the BizTalk 2006/2009 SMTP adapter can take care of the correct MIME encoding (but if the content is already MIME encoded inside the pipeline it is kept intact). According to various blog entries the new SMTP adapter's MIME encoder will take care of setting the correct content-type.

I preferred a small update to my existing code instead of a global rewrite to leverage these new options.
Luckily you can override the MIME encoder's default by specifying the content type of the XLANGPart like this:


part.SetPartProperty(typeof(Microsoft.XLANGs.BaseTypes.ContentType), contentType);

The only thing left to-do is to find out the correct MIME-type per attachment. I have wrote a small function that does exactly that by using the file extension:















etc...


The default content-type for unknown extensions is "application/octet-stream".
This alone could have been enough to fix the issue but I've tried to put in as much detail and content-types as are documented here.

Here is a sample class (original sample credits go to Tomas Restrepo with content-type update).

posted @ Monday, July 13, 2009 6:35 AM | Filed Under [ BizTalk - EAI - B2B ]

Comments

Gravatar # Post number 109 on geekswithblogs.net
Posted by GlenStef on 7/13/2009 10:28 PM
Hi there,
Super post, Need to mark it on Digg
GlenStef
Post A Comment
Title:
Name:
Email:
Website:
Comment:
Verification: