Month: September 2008

Update: As Omer points out in the comments to this entry, the recommendations made in the DBA Checklist mentioned below are in places at odds with the official BizTalk/SQL Server best practices. When reviewing the checklist, please refer to the Microsoft BizTalk SQL Server Best Practices KB article.

SimpleTalk has a helpful DBA checklist for all those BizTalkers who double-hat and manage a SQL Server as-well-as a BizTalk environment. It covers a number of useful topics, including:

General best practices

High-availability

Performance tuning

Application coding and design

SSIS, Analysis Services, Reporting Services & Service Broker

Plenty of content for both new and experienced DBA’s – well worth a look.

Related articles by Zemanta

The next UK SOA/BPM User Group Meeting has been announced which will be taking place on Tuesday, 14th October 2008 at Microsoft’s London office.

The meeting will include an introduction to BizTalk 2006 R3 2009, a presentation by ISV Frends Technology on integration solutions, plus developer and architecture sessions; there will also be beer and pizza. Full details can be found at the UK SOA and BPM User Group website.

Completely off topic for this blog, but interesting nonetheless: Verisign yesterday reported that they processed more that 48 billion DNS queries per day in the second quarter of 2008. Wow.

VeriSign also maintained 100 percent uptime for the DNS system during the second quarter, as it has for the past decade. I think this must be one of only a handful of cases in the industry, given how elusive even 99.999% uptime is.

In my reply I suggested that he looked at assembly redirection, which allows developers to redirect one version of an assembly to another, through changes to an executable’s .config file – in our case, btsntsvc.exe.config. Having never done this in anger in BizTalk, I though this would be a good opportunity for a blog post – here are my findings.

Configuration Changes

To enable assembly redirection, the following lines need to be added to the runtime/assemblyBinding element in the .config file

On line 4, we identify the assembly we wish to redirect; on line 5 we identify the new version. If we had wanted, we could specify a range of ‘old’ assemblies that are to be redirected, as follows:

1: <bindingRedirectoldVersion="1.0.0.0-1.2.0.0"newVersion="2.0.0.0"/>

Restart the Host Instance/s for the redirect to take effect. If the new version of the assembly cannot be found in the GAC, you will only see an error when the CLR attempts to load the assembly at runtime, not when the Host Instance restarts, the error is a usual favourite:

Error details: Object reference not set to an instance of an object.

Testing Redirection: Orchestrations & Maps

To test the redirection, I created an orchestration and map that invoked simple helper classes contained within a separate assembly. The helper classes expose a single method which takes two strings as input parameters and returns a concatenation of the these two parameters – an example of the version 2.0 code can be seen below. Versions 1.0.0.0 and 2.0.0.0 were deployed to the GAC.

Four messages were submitted into BizTalk; in-between the second and third messages, the assembly redirection code was enabled to point to version 2 of the assembly and the Host Instance restarted. The results of the test can be seen in the DebugView screenshot below – once the redirection config change is applied, both the Map and Orchestration start to use the version 2 of the assembly:

Conclusions

A few conclusions can be drawn from this test:

Assembly redirection can be used within BizTalk for helper classes in both Orchestrations and Maps (on ports & in orchestrations). There are other cases I can think of, such as pipeline components, for example.

The signatures of these helper methods must remain the same between releases.