Nick Heppleston’s experiences as a UK BizTalk Consultant
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.
More info over at Data Centre Knowledge.
Over on the BizTalk Gurus Forums, Richard Wallace asked for opinions on best practice for central business logic that would span over a number of BizTalk applications. One of his suggestions was to use .Net assemblies that contained this business logic, however he was concerned about the re-build / re-deploy tax that this would introduce into his BizTalk projects if he needed to change his business logic assemblies.
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
1: <runtime>
2: <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
3: <dependentAssembly>
4: <assemblyIdentity name="BizTalkAssemblyRedirectionHelper" publicKeyToken="5cce5ee5c1d7dc25" culture="neutral" />
5: <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0" />
6: </dependentAssembly>
7: </assemblyBinding>
8: </runtime>
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: <bindingRedirect oldVersion="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.
1: using System;
2: using System.Diagnostics;
3:
4: namespace BizTalkAssemblyRedirectionHelper
5: {
6: [Serializable]
7: public static class RedirectionHelper
8: {
9: public static string ConcatHelper(string a, string b)
10: {
11: Trace.WriteLine("RedirectionHelper - Orchestration, version 2.0.0.0");
12: return (a + b);
13: }
14: }
15:
16: public class RedirectionMapHelper
17: {
18: public string ConcatMapHelper(string a, string b)
19: {
20: Trace.WriteLine("RedirectionHelper - Map, version 2.0.0.0");
21: return (a + b);
22: }
23: }
24: }
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:
Encountered the following error today on a SOAP [Send] Port:
Failed to serialize the message part “[PART NAME]” into the type “[MESSAGE TYPE]” using namespace “[NAMESPACE]“. Please ensure that the message part stream is created properly.
The error is a little misleading, especially ‘ensure that the message part stream is created properly‘ - the message part stream is created correctly, but it does not match the type contained within the SOAP adapter proxy and therefore fails to serialize. In our case, we were trying to serialize an element with the string ‘Stan’ into a boolean. With the best will in the world, that isn’t going to happen!
To check where the problem lies with serialization, simply validate the failed message (retrieved from the Admin Console) against the schema generated from the WSDL, using the Visual Studio ‘Validate Instance‘ schema menu option. You’ll be presented with a list of errors that can then be resolved.
Our problems went a lot further and resulted in a fairly impressive hacky bodge that I am extremely proud of, especially on a Friday at 5pm (with a Bank Holiday weekend waiting for me). I’ll spare you that for another post!
In the good old days of BizTalk 2004 (who am I kidding?!?), compiling a project that contained an orchestration resulted in the C# generated from the XLANG/s to be placed in the same directory, allowing you to put your C# guru hat on and review the code.
While trying to decipher a cryptic BizTalk error message today, I decided to go delving into the generated C# to try and figure out which shape related to ’segment2′. It turns out that by default, BizTalk 2006 doesn’t provide this functionality.
Thankfully, Arnulfo Wing has sorted this out and provided the instructions to re-enable this helpful piece of functionality through some registry settings and a Visual Studio restart. I haven’t come across his blog before, but it has some great content on all things BizTalk - I suggest you check it out: http://arnulfowing.blogspot.com/
As announced on the Simple-Talk blog, Red Gate software will be responsible for the future development of .NET Reflector, the popular tool authored by Lutz Roeder. Red Gate will continue to offer the tool for free to the community.
I think this is great news for an already excellent tool and although there doesn’t appear to be any enhancements already in the pipeline, the Red Gate team plan on going out into the community to get suggestions on how to make the tool even better.
.Net Reflector can be downloaded from the Red Gate website at: http://www.red-gate.com/products/reflector/