Warning on ‘maxConnections’ and ‘autoConfig’ parameter

When optimizing a BizTalk environment one thing you can do is change the value for the ‘maxConnections’ setting. As stated on the MSDN site (http://msdn.microsoft.com/en-us/library/aa561380.aspx) this setting determines how many connections can be made to a specific IP address. The same article on MSDN also contains the following text:

 “If the BizTalk Server computer is running ASP.NET 2.0 or later then you can set autoConfig=truein the processModel section of the Machine.config file to automatically configure the following settings to achieve optimal performance based on the machine configuration”

This totally contradicts the following statement in the best BizTalk book around:

“ASP.NET 2.0 introduced a self-tuning feature to counter this issue whereby it will set the maxConnection value to a sensible value. This only applies to HTTP or Web Service requests created within ASP.NET 2.0 not BizTalk, so the above still applies to BizTalk solutions.”

I have tested this on my development box and it turned out that the MSDN content is not correct. The ‘autoConfig’ setting does not apply to BizTalk.

A new life for my PowerShell provider for BizTalk

A couple of weeks ago I was contacted by Maxime Labelle and Michel Hubert (BizTalk MVP) who accidentally found my PowerShell provider for BizTalk.  The funny coincidence is that they had just finished their own version of the provider without knowing about the existence of mine.  

I didn’t take  much time for us to decide to join forces. We are currently in the process of merging the two source bases and planning for the next release. 

I’m very happy to have the chance to work together with Maxime and Michel on this project. I also think the merge brings benefits like higher (code) quality and  higher release frequency.

This  next release will be the one and only PowerShell provider for BizTalk (I hope) and will be available on codeplex. My version will be downloadable from here until the first joined effort release is available.

Unleashing the spool table (well at least partly)

Today was one of those days that I couldn’t resist my need to find out what happens under the BizTalk covers. I think every BizTalk developer recognizes this.

In particular I wanted to examine the context properties of message stored in the spool table. The reason I wanted to do this is a little bit irrelevant for now and might eventually come back in a future post or article.

Anyway, the spool table has a very simple structure:

CREATE TABLE [dbo].[Spool](
    [uidMessageID ] [uniqueidentifier] NOT NULL,
    [UserName] [sysname] NOT NULL,
    [PublishingServer] [sysname] NOT NULL,
    [OriginatorSID] [sysname] NOT NULL,
    [OriginatorPID] [nvarchar](256) NOT NULL,
    [dtTimeStamp] [datetime] NOT NULL,
    [dtExpiration] [datetime] NULL,
    [nvcMessageType] [nvarchar](128) NULL,
    [nNumParts] [int] NOT NULL,
    [uidBodyPartID] [uniqueidentifier] NULL,
    [nvcBodyPartName] [nvarchar](256) NULL,
    [nCounter] [int] NOT NULL,
    [imgContext] [image] NULL )

The column I was interested in is called ‘imgContext’. For each message this column stores an encoded serialized value of the collection of context properties, something like this:

0xC4E0906C1849D311A24200C04F60A5330500000074000000680074007 etc, etc….

For my experiment I wanted to work in code with IBaseMessageContext interface much like the way we do when coding custom pipeline components.

So the question was how can I directly create a IBaseMessageContext instance from ‘0xC4E0906C1849D311A……’?

After clicking around for quite a while in Reflector I was able to create a very simple console application that gave me access to the context of the message. The only thing I needed to provide was the Message ID which can be fetched from the column ‘uidMessageID’ or the BizTalk Administration Console. Here is the code:

Running writes the context properties to the console:

I hope this code will help someone who, like me, also has the need to go beyond the BizTalk borders 🙂

A couple of notes:

• This code is only for ‘research’ purposes and should never be used in production environments or any other purpose.
• If you want to do this. Make sure the message stays in the spool table. If the message is processed by BizTalk and everything went fine the message will be deleted from the spool table. To prevent this you can set a breakpoint on the processing orchestration, create an error or disable the BizTalk Sql agent jobs.
• The code was developed using BizTalk 2009 but should also work in previous versions.