Exceptions in BizTalk Server’s Server’s execution model are somewhat similar to the Windows Application that we recently blogged about. Generally, an integration transaction starts from an origin system, and it ends at a destination system. Within this “Integration” we will find several points of potential failure which we should do something about. . . the what we should do, depends on the particular location and method of failure. For example, if our source system is a Database Server, and our destination system is a Web Service Call, generally the points of potential failure are: The call to the Database to get the data, the parsing of that data, the transformation done to the data, business rules, the call to the Web Service to deliver the data, and finally the response of the Web Service call. In any of these steps there is a chance for a failure (if we assume that BizTalk Server doesn’t get rebooted or have hardware failures).
Each of these potential modes of failure needs to be trapped, and a failure that occurs in those points needs to be routed to different places and personnel to resolve the failure. IE: the person who can fix bad data existing in the origination database, is not necessarily the same person who could or should fix a failure in a transformation, and neither of them are probably the same person who can fix a missing response to a sent outbound message. These different modes and locations of failure need to be trapped differently, and routed differently, because they need to be resolved differently.
Execution and Exceptions in BizTalk Server
BizTalk Server has two types of executions. The simplest one it is called “Content Based Routing”, which is a straight way of executing a transaction. It is fast and it uses the least amount of resources, however, it is somewhat limited. We implement Failed Message Routing to handle exceptions in BizTalk (MSDN Reference). The other main type of execution is Orchestrations (MSDN Reference). This one gives much more control to the developer, but it is much more taxing to the server. Each requires a different way to handle exceptions in BizTalk. Orchestrations in essence are C# classes. They get translated by the compiler and executed just like any other C# Object, therefore it makes usage of the actual C# exception handling process. Content based Routing on the other hand, since they don’t have their own Class, run on some other Process. This means that we have to adapt to the standards established by the product. Specifically, BizTalk provides special flags to the transaction (when they fail) so that they can be filtered and routed appropriately without letting them queue in the system, until a BizTalk Administrator releases them.
Come back next week and check our new post about “What happens if we don’t Handle BizTalk Exceptions?” and “What is the best practice, per Microsoft?”