Cross Roads: Advance mechanism to handle exceptions for .net component used inside BizTalk solution

Finally after one month’s big vacation I am writing something technical, few days back my one of good friend came to me and asking me about the exception handling inside BizTalk for those scopes which contain calls .net classes and their methods. Well, I enthused about this article, and also a good chance to document some good practices I have worked for in some previous projects to improve the exception management and automating support routing. The article also includes some videos, hope it will help you to understand my views and idea about this mechanism I am presenting here.

In every system or solution exception handling stands with primary requirement, this article is not elaborating exception handling fundamentals in .net platform but I am focusing towards exception handling in .net component which we are adding as assembly inside BizTalk Solution/Project. Those exceptions handled inside .net assembly then the question comes how we can manage execution flow if exception occurs with orchestration logical flow, need to put flags, variables, calls and then with decision shape we can route files or log it within orchestration, correct. Hummm, it’s really odd solution, it can surely fulfill our purpose but it’s not recommended. This is very heavy on orchestration as well not recommended for runtime performance of BizTalk orchestration. Well, there is always an Generic Exception we can handle inside Orchestration for any scope but it will not give specialized block to handle such exceptions like if I want to handle DivideByZeroException and NullReferanceException in different block and then I want to divert the files at different Send Port so my technical support team can look and appropriately correct them individually and send those back for reprocessing, so I can give my customers better and fast experience with BizTalk support group.

An unhandled exception inside .net class which you can surely catch inside BizTalk Orchestration as Generic Exception. But If you have requirement like you need to execute few statements to compensate and then you also want catch that exception inside BizTalk Orchestration to route the logical execution path. Bit confusing requirement but believe me it’s normal one, there you will question me, why I shouldn’t catch inside BizTalk only and execute all compensate statement inside catch block, really possible but it will be not appropriate for performance, suppose if you handled it inside .net assembly then assembly call, refection will improve run time assembly performance inside BizTalk rather then calling multiple time. Yes then the question, what to do about the logical execution flow inside Orchestration, if the requirement want to route the message to any other branch or to any send port if exception occurs, possible? We can rethrow the exception inside .net assembly’s catch block after the compensation has been executed inside code, rethowed exception will be catch by BizTalk orchestration and we can route logical flow as per the requirement.