BizTalk Blogging Year In Review
Just a bit over a year since I started BizTalk blogging, so I thought I'd take 5 minutes and review the posts of the last year (126!?!)
and try to find some highlights.
- Most Searched For Post. It's a pretty close tie between my series on SQL Updategrams ( part 1, part 2) and an end- to-end walkthrough of a Single Sign On (SSO) scenario.
**Most Comments.** - My post on [passing "anything" through BizTalk](../richardbpi/processing-pdfs-or-anything-else-in-biztalk-orchestrations) seemed to spawn lots of chatter.
- Most Self-Educational Post. The posts I learned the most by writing include how to do
BAM for looping processes, how
to correlate untyped messages, and
how to do an aggregation pattern on large batch files. - Most Criminally Unread Post. Apparently
Role Links aren't very interesting to folks as I got no feedback on this bad boy. Anyone? Bueller? - Best Plagiarized Post. My original post outlining the considerations when using
context properties and the rules engine apparently
was good enough to steal. Quite flattering. - Most Controversial Post. I'm probably as controversial as a basket of puppies, but my
feedback on the BizTalk 2006
beta exam yielded some interesting chatter.
It's been a fun year, and I greatly appreciate the feedback and suggestions the community has provided.
Technorati Tags: BizTalk
Comments
- Anonymous
July 10, 2006
The comment has been removed - Anonymous
July 10, 2006
Have you tried calling the receive pipeline from an orchestration and catching the exception there? - Anonymous
July 11, 2006
The comment has been removed - Anonymous
July 11, 2006
What sort of exception are we talking about? Validation failure? BizTalk 2006 does offer recoverable interchanges which means that you can choose to have failed messages get suspended, while any valid messages in the batch get committed. - Anonymous
July 12, 2006
The comment has been removed - Anonymous
July 12, 2006
BizTalk 2004 behaves the way you describe, but BizTalk 2006 allows for disassembled batches to treat each record uniquely, and you can choose to NOT suspend the entire message if a bad record is encountered. You can't change this behavior in BTS 2004, but 2006 offers the ability to continue processing after a "bad" record is encountered. - Anonymous
July 12, 2006
The comment has been removed