Microsoft

This article assumes that you already have an optimal data model along with the most efficient data tier in your application.  You’ve spent plenty of time optimizing indexes, poring over the SQL explain plans, and tuning the SQL queries that your application uses to retrieve data from your SQL Server database.  The application has been running fairly smoothly, performance isn’t great but has been acceptable to the end users.

At some point, due to application load from the users, data volume, or other external variables, you notice that the queries you optimized utilizing the Management Studio’s estimated explain plan do not perform as expected. 

Let’s take a look at the table we’ll be querying.  We’re using the VARCHAR data type to store all string data in our database.

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.  More often than not, the result of selecting the wrong shape for the job is not seen until the application is tested or even worse, the production environment.  One of the primary reasons that BizTalk is used is the opportunity to build loosely coupled, flexible and scalable applications.  By choosing the wrong shape, many developers will wind up doing exactly the opposite, thus setting the application down the course of tight coupling and brittle implementation. 

BizTalk development on virtual machines has become an essential part of the development process.  The speed with which you can tear down and build up BizTalk VMs means you spend less time configuring environments and more time developing artifacts.  Typically, an instance of one of these environments contains everything (BizTalk, SQL Server, Visual Studio, etc.) running on a single VM machine.  Spinning up a new development environment is as easy cloning your base image.  Occasionally, though, you need a development or sandbox environment that’s a little more than a virtualized BizTalk “island”, of sorts, with everything running on a single VM.  

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.  When the code sample is used as it is presented against a service based on the SOAP 1.1 specification, the user will most likely see an error like System.InvalidOperationException: Unable to find match for inbound body path expression.