BizTalk

During my evaluation of BizTalk Server 2013 and the ESB Toolkit 2.2, I ran into an issue running one of my favorite components, the ESB Management Portal. I followed the set of instructions for installing and configuring the portal which were essentially the same as the ESB Toolkit 2.1 instructions. When I tried to navigate to the home page, I received a number of errors:

Picking up where we left off in the Service Bus Introduction, this post will walk through a Relayed Messaging sample in order to highlight how the AppFabric Service Bus could be utilized to build Hybrid applications. In addition to the basic sample, I will also demonstrate how to provision a BizTalk Server 2010 Receive Location on the Service Bus.

Earlier this week I participated in a discussion thread on LinkedIn regarding the usage of the WCF SQL Adapter in BizTalk Server and I wanted to summarize some of my thoughts and the recommended best practices regarding this particular scenario.

The reports of my death are greatly exaggerated. ~Mark Twain (or BizTalk Server)

For the past 5 years or so, various technologists have been predicting or even proclaiming the untimely demise of Microsoft BizTalk Server. Usually these predictions come in the form of blog posts espousing the new hotness whether it was a new product from Microsoft or a competing product claiming it was a better middleware solution than BizTalk. Oddly enough, the chatter ramps up the loudest shortly after Microsoft releases a new CTP of technology X that may be tangentially related to an existing product like BizTalk.

In an effort to maintain control over the proliferation of application servers and data, many organizations have undertaken projects to consolidate and integrate systems. One of the first hurdles in undertaking an integration project is determining the most efficient integration technology. Unfortunately, just within the Microsoft stack, there are technologies that consistently cause confusion and are often misused.

During my past BizTalk engagements, I have had the opportunity to work closely with my clients in developing flexible and maintainable applications. One of the most common issues that I come across is the misuse of some of the shapes available within the Orchestration Designer. By misuse, I simply mean to say that many BizTalk developers will drag and drop shapes into an orchestration to implement the business process, but do not take into account the implications of doing so.

In the BizTalk Server 2009 documentation for the topic How to Handle Typed Fault Contracts in Orchestrations, the documentation assumes the reader is calling a web service based on the SOAP 1.2 specification. The code sample presented will not work if the user is configuring a WCF Send Adapter to call a web service based on the SOAP 1.1 specification.