BizTalk 2004 together with Visual Studio 2005

".Net assemblies can be deployed and run side by side" – remember this sentence?
Well, in general it is true, but there are some caveats you have to remember. First one, web applications are usually bound to some version of .Net runtime. So, if you install .Net framework 2.0 and in the same time BizTalk 2004 wizard relies on .Net framework 1.1 – there will be a confuse definitelly, when publishing orchestrations as web services. There might be also other problems for the BizTalk runtime itself, so it is worth to update BizTalk configuration itself.
To keep things short, if you have VS.Net 2005 and BizTalk 2006 on one box, just keep in mind (or bookmark, or remember keywords for the search engines) these URL’s:

When there is a lot of service instances …

If you look at BTS performance blog (can be found here) then you know that you have to monitor the size of the spool table. And this is true.
Some long time ago (sorry, didn’t had time to blog about it that time) we have faced situation, when problems were caused not by multiple messages in the spool table, but rather a lot of service instances associated with BizTalk Isolated host.
We had a situation, when the application that was bound to BTS isolated service host stopped working. After long, long, long, long, long time of research together with MS PSS we have found out that it was due to >15 billion of service instances hanging there . Yes, it is true, not million – Billion (with 9 zeros).
When the SOAP receive port was moved to another isolated host – it started working again, but still there were more than 15 billion service instances in the DB. As you can imagine, DB size was also pretty impressive.
And then … another "project of the year" with MS PSS was started. Goal was to remove the service instances from DB in a supported way.
All utilities (like BtsMsgTerm) were failing with "Out of memory exception" (I would expect that) and scripts were failing by not removing instances any way. At the end I took the initiative.
First – the SQL script that verifies the situation (to see if the instances are getting terminated, when the script runs):
DECLARE @cActive bigint
DECLARE @cSuspended bigint
SELECT @cActive = count(*) FROM dbo.BizTalkserverIsolatedHostQ WITH (NOLOCK);
SELECT @cSuspended = count(*) FROM dbo.BizTalkserverIsolatedHostQ_Suspended WITH (NOLOCK);
SELECT @cActive+@cSuspended
After some research with BizTalk help I have end up with some VB script that terminates the instances in batches, but there were two issues:
a) "SELECT * FROM MSBTS_ServiceInstance WHERE HostName = ‘BizTalkServerIsolatedHost’" was not returning all instances (I would not expect someone returning 15 billion objects either).
b) Sometimes when looping through collection the same instance at the end was returned zillion of times (strange one)
Therefore I had to restart the script again and verify if the next instance received from collection is not the same as previous one.
So, after these modifications, with the help of VBScripts famous On Error Resume Next and simple command line script – I’ve got rid of those billions of messages in a few days in a supported way.
Of course, the issue was resolved step by step: first by the SP1. If You have not applied for some reason – you definitelly should do it NOW.
Later, there was another KB: 
What is the morale of this post:
a) Check the database sizes
b) Monitor important tables (e.g. spool)
c) Add service instance counter to your monitored objects
If you are experiencing something like that and want to get the script, just give me short e-mail, but in general you should do the job by taking the sample and modifying it appropriatelly.

MSDTC configuration

Today I’ve been playing with BizTalk 2006 remote scenarios and of course ran into MSDTC configuration issues.
I have BizTalk administration utilities installed on my PC, and BizTalk with the SQL Server was running on the Virtual Server.
When I was trying to expand applications container (on the client machine) I was getting message like:
"Error during policies enumeration. Check if your MSDTC settings for remote network clients are set up properly.".
So, I started to check everything step-by-step:
a) Ensure that MSDTC network access is allowed on all machines (client, BizTalk, SQL if any).
Check the chapter: "To configure the BizTalk Server 2004 computer"
b) Turn off RPC security

After going through all of this, administration console was still throwing these messages at me.
I ran the test, but it was teeling that either firewall is not open (I didn’t had any) … the usual stuff.
After a while I have tryed change the MSDTC configuration and instead of using local MSDTC, I have changed to the BizTalk Server. After this, DTCTester lost any connection to the MSDTC.
After a little research I found the problem. It was the TCP/IP or to be more exact WINS configuration.

c) Enable NetBIOS on your network adapter (usually I keep it disabled). Take the following steps:
  • Open Properties for the network adapter
  • TCP/IP Properties
  • Advanced and select WINS Tab
  • Ensure that the "Enable NetBIOS over TCP/IP" is selected

After enabling this setting MSDTC problems dissapeared.

Though, other problems started showing up.

Windows Workflow Foundation …

You can find some sneak preview here.
Nice name . Everything is called now with the "foundation", like presentation Foundation (Avalon). It looks like that BizTalk will have use this foundation.
Just think about:
Currently BizTalk is all about messages and persistance. What about scenarios where persistance is not required, or application business workflows (usually hosted in-memory)?
I think WWF should provide solid "foundation" for all these scenarios.

Integration and SOA patterns

Recently there was a discussion between me and business system owners in the company.
We were discussing about integrating various platforms and technologies using BizTalk.
The initial question that started the discussion was pretty simple: does BizTalk supports CORBA, SNMP, Telnet and TL1. As You may guess, all this is for telecommunication services.
You can easy find an adapter for CORBA from, there are no adapters for other protocols though (or at least I didn’t found them through MSN Search). If there is no such adapter, You could build one that enables communication between BizTalk system and other systems that are on the wire using Telnet or SNMP, but … at that point I thought about SOA patterns. Ron Jacobs was talking about these patterns during the Teched 2005 in Amsterdam. Also, these were published in MSDN:
When I thought about these and other patterns listed there:
one thing came to my mind: "I don’t think it is a good way to do the stuff". Why?
Experience tells me that such protocols are tended to be chatty, with no strict schema behind. If implemented in BizTalk directly, BizTalk application would turn it into tightly coupled part of that system. Later on, when new functionality is added (from the system perspective, not from the business perspective) or version is updated, BizTalk solution will have to be updated as well.
What I have suggested is to surround those systems with services. Services, which would have schema, policy, contract defined and would be business oriented, not – technology. A little apps (web services, unix scripts, etc.), which would hide the system internal things and would communicate with the outside world through the messages (SOAP, Files, etc.). After these thoughts everything came to the right places.
So, these were thoughts of mine. If you have some opinions, please do not hesitate to add your comments here.

Some BizTalk articles

KB’s for BizTalk

If You are BizTalk developer or administrator and accidentally  missed this feed, then I would recommend to subscribe to it.
P.S. IE7 shows feeds (RSS) in a nice page, I like it . Thanks for IE7 devs …

New things in BizTalk ODBA

In 2004 – ODBA (Orchestration Designer for Business Analyst) was a tool to design conceptual view of the business processes.
In 2006, in addition to the same business process design, new features for BAM integration were added (the Excel is still available). So, in general You can define the conceptual view of the process and data of interest in one place.
To see how it looks like, check this post.
P.S. I have separated BizTalk stuff from the rest of the .Net development into a separate category, because I think, BizTalk deserves to have one .