Here’s one scenario you want to avoid. The Sql servers were rebooted and since they didnt come back up within the default error threshold of 5 the receive location on the Biztalk receive was disabled. This led to a lot of messages getting accumulated. When having many third party systems and a tightly integrated system and fairly complex we were looking in all the wrong places for the missing messages. It took some time to find out that the sql receives were disabled. So it might be a good idea to set this threshold to zero. Since zero never happens the receive is never shut down in case of a communication failure. And you dont have to worry about disparate systems getting rebooted. After all what all can you account for?

Catch is this setting varies for different adapter.

For SQL its on the SQL Adapter

For File its right on the receive location configuration.

Well in my case ; it got created on some boxes and not on others. We were assuming its some configuration thing. Until MSTech clarified ; well it was configuration but more like solution configuration. It’s created when you build as “Development” configuration. Not when built as “Deployment”. It was interesting to know..

An attempt to use an IP protocol that is not available on the system has been made. 

Install the required IP protocol or use an IP protocol that is available on the system. This error can also occur if the system is short of memory or other system resources.
****************************************************************************
If you have WebSphere MQ 6.0.* version client, BizTalk Adapters for Host Systems – you are bound to run into one of these issues with the MQSC adapter.

Or maybe only i was the unlucky ones. This left me handicapped for a few days when i needed to push critical fixes and could not test my orchestrations because of the dependency on the queues.

I upgraded from MQ 6.0 to MQ 6.0.2.1 and started receiving these errors whenever i enabled my receive locations which were MQSC receives.

I used ProcessMon to narrow down the issue.
I started ProcessMon and then enabled the receive and then stopped processmon.

The key events to look for would be from BTSNTSvc.exe process. If you follow the reads it would lead you to amqxms0n.dll. This dll is used to write to the error log for WebShphere MQ in folder X:\Program Files\ibm\WebSphere MQ\errors. So thats too far. If you look at the last read before accessing the error logger dll and follow its stack trace; you will possibly be able to trace it.

In my case what happened was one the WebSphere dll’s loaded was from the X:\windows\system32 which was older than the one available in the X:\Program Files\ibm\WebSphere MQ\bin folder. The latest ones i got during the upgrade. SO i had to identify and physically move them.

The errors seems more cryptic though and i spent more time researching based on the error messages which lead me nowhere.
Most of the issues i dealt with earlier too i was able to narrow down to path problems or missing dlls in specific paths using FileMon.
The error thrown by MQSC seems to be the wrong lead to follow.

Refer MSDN for the entire set of classes.

Open the BizTalk admin console and query analyzer to the database where the BizTalk is configured. Verify the number of connections currently used.
Click on the “Applications” node in the BizTalk console and hit Refresh.

Now rerun the query and  you will see atleast 15 more new connections. Everytime you refresh that many new connections pop up. The query you use can be as simple as running “sp_who”.

In the Development enviroment its allright. When it gets to the test or user acceptance enviroment ; its probably not such a good idea to have many developers connect to console and hitting refresh.

These connections do not die until the BizTalk admin is actually closed.
BAM is the best alternative. HAT is also the easiest way to go about. HAT opens only 1 or 2 connections.

Keys : btsmmc.msc; btshatapp.exe

Description:
An error occurred that requires the BizTalk service to terminate. The most common causes are the following:
 1) An unexpected out of memory error.
 OR
 2) An inability to connect or a loss of connectivity to one of the BizTalk databases.
 The service will shutdown and auto-restart in 1 minute. If the problematic database remains unavailable, this cycle will repeat.
 
 Error message: Exception of type ‘System.OutOfMemoryException’ was thrown.
 Error source: mscorlib

****************************************************************************

If you are seeing these kind of out of memory exceptions more frequently on the event log of your BizTalk Server ; its probably a good time to reorganize the biztalk project. There are plenty of best practices and white papers published which offer good guidance. But most likely situation is that your architecture is already in place and you might be well into development or even production to do design level changes.
Here are some considerations that can be done without too much chaos.

Divide orchestrations,transforms,schemas and web references into separate assemblies. Usually the transforms are the culprits ; because if they are large(physical disk size)  and if you are going to be working on large chunks of data at run time ; the memory required for that will be higher at run time.
Break away large transforms into smaller assemblies of their own if you think its getting too big at the same time being cautious of not getting too granular.

Be extremely wary about functoids that ship with BizTalk 2006. Some of the functoids are implemented as inline scripts resulting in the building of a System.Byte array in memory. Scripting with Inline C#, String,Math,DateTime are all inline scripts.Refer Microsoft support for more information on this. Extract from there..

The System.Policy.Security.Evidence object is often used in transforms and can consume a lot of memory. Whenever a map contains a scripting functoid that uses inline C# (or any other inline language), the assembly is created in memory. The System.Policy.Security.Evidence object uses the object of the actual calling assembly. This situation creates a rooted object that is not deleted until the BizTalk service is restarted. We recommend that you call an external assembly instead.

Best practice – when using many inline scripted functoids try to separate out the assembly to smaller sizes

VS2008 does not support any version of BizTalk server for development.

BizTalk 2006 and 2006 R2 work with VS 2005 alone.

For a biztalk developer who works on orchestrations,manipulating messages and data in them,debugging on a day to day basis ; it becomes practically impossible to see the 360 degrees. There will remain some portions that we would not have exploited on a day to day basis.

Taking the certification evens out exactly that. In my case i had not worked or implemented BAM and found out a lot by reviewing examples and implementing them.

Overall; if you are a consultant and do provide solutions, design suggestions – it is a value add to know the 360 degree angle of BizTalk to do your best.

I began and probably did only BAM completely. I was comfortable with BRE and other orchestration,messaging stuff. The emphasis on BAM/BRE in the exam cannot be understated. Saravana Kumar’s blog gives a good write up on preparations. Its excellently summed up.

I used BizTalk 2004 Unleashed and BizTalk 2006 Recipes for references. Pracital experience is the saviour.I will share my transcript as it becomes available . (Took exam on 9/21/2007)

Microsoft Exam – 70-235.

But wanted to be done with the certification before i do it.

So here it is. Look forward to some stuff on biztalk on my blog. Will post more on the certification too.