While investigating some BizTalk performance issues at a client I noticed that several of their receive ports, send ports, and orchestrations were tracking the message bodies.
After enquiring around we came to the conclusion that nobody there expects message bodies to be tracked, and that they are getting purged by the DTA SQL Server job. This is just adding a massive amount of unnecessary processing to their system. This message body tracking settings either crept into Production within MSIs from development and test, something to be very aware of, or the settings were inadvertently enabled for some reason and never disabled back.
The default tracking options in orchestrations are “Orchestration start and end”, “Message send and receive”, and “Shape start and end”. The default tracking for ports is none (the events for ports is done by the pipelines, which I left out of this on purpose).
So I created a little command line tool to set all ports and orchestrations back to the BizTalk default. You can see that this is a very simple example of how to get and modify tracking settings from ports and orchestrations. From here you can build a very powerful “BizTalk Tracking Manager” application even! Don’t forget to refresh the BizTalk Administration Console if it’s open while you run this.
Note: I made an exception on the receive port called “BatchControlMessageRecvPort” that gets created automatically when EDI is installed with BizTalk 2006 R2. Please be very careful when using this and investigate and test it fully before running it. Only intended for BizTalk 2006 and 2006 R2 versions.
Hope it’s useful to someone!
using System;
using System.Collections.Generic;
using System.Text;
//Add a reference to Microsoft.BizTalk.ExplorerOM.dll
usingMicrosoft.BizTalk.ExplorerOM;
using Microsoft.Win32;
namespace RevertBizTalkTracking
{
class Program
{
static void Main()
{
Console.WriteLine();
try
{
BtsCatalogExplorerbtscat = new BtsCatalogExplorer();
Console.WriteLine(DateTime.Now.ToLongTimeString() +
" Connecting to local BizTalk server");
string btsConnectionString = GetBTSConnectionString();
if (btsConnectionString != string.Empty)
{
btscat.ConnectionString = btsConnectionString;
Console.WriteLine(DateTime.Now.ToLongTimeString() +
" Looping through receive ports");
//Loop through all receive ports
foreach (ReceivePortrcvport inbtscat.ReceivePorts)
{
//skips the EDI port created in 200 6R2
if(rcvport.Tracking != 0 & rcvport.Name
!= "BatchControlMessageRecvPort")
{
Console.WriteLine(" " + DateTime.Now.ToLongTimeString()
+ " Port "+ rcvport.Name + " with tracking ("
+ rcvport.Tracking.ToString()
+ ") enabled. Changing port back to default.");
//Sets it back to the default value
rcvport.Tracking = 0;
}
}
//Loop through all send ports
Console.WriteLine(DateTime.Now.ToLongTimeString()
+ " Looping through send ports");
foreach (SendPortsndport inbtscat.SendPorts)
{
if(sndport.Tracking != 0)
{
Console.WriteLine(" " + DateTime.Now.ToLongTimeString()
+ " Port "+ sndport.Name + " with tracking ("
+ sndport.Tracking.ToString()
+ ") enabled. Changing port back to default.");
//Sets it back to the default value
sndport.Tracking = 0;
}
}
//Loop through all orchestrations
Console.WriteLine(DateTime.Now.ToLongTimeString()
+ " Looping through orchestrations");
foreach (BtsAssemblybtsasm inbtscat.Assemblies)
{
foreach (BtsOrchestrationorch inbtsasm.Orchestrations)
{
if(orch.Tracking != (OrchestrationTrackingTypes.ServiceStartEnd
| OrchestrationTrackingTypes.MessageSendReceive
| OrchestrationTrackingTypes.OrchestrationEvents))
{
Console.WriteLine(" " + DateTime.Now.ToLongTimeString()
+ " Orchestration "+ orch.FullName + " with tracking ("
+ orch.Tracking.ToString()
+ ") enabled. Changing orchestration back to default.");
//Sets it back to the default values
orch.Tracking = (OrchestrationTrackingTypes.ServiceStartEnd
| OrchestrationTrackingTypes.MessageSendReceive
| OrchestrationTrackingTypes.OrchestrationEvents);
}
}
}
//Apply changes
btscat.SaveChanges();
Console.WriteLine("Finished! Press any key to exit.");
Console.Read();
}
}
catch (Exception ex)
{
Console.WriteLine("Exception raised: " + ex.Message);
Console.WriteLine("Press any key to exit.");
Console.Read();
}
}
//Creates the connection string based on values in the registry
//From Carlos Medina's blog - http://blogs.devdeo.com/carlos.medina/PermaLink,guid,981d7ca5-a11a-452b-90d5-a535d04a64bf.aspx
public static string GetBTSConnectionString()
{
string connection = string.Empty;
string server = string.Empty;
string database = string.Empty;
using (RegistryKeykeyBts =
Registry.LocalMachine.OpenSubKey(@"SOFTWARE\Microsoft\BizTalk Server\3.0\Administration"))
{
server = keyBts.GetValue("MgmtDBServer") as string;
if (server == null)
server = string.Empty;
database = keyBts.GetValue("MgmtDBName") as string;
if (database == null)
database = string.Empty;
}
if (server == string.Empty || database == string.Empty)
{
Console.WriteLine("Error getting connection details from registry:");
Console.WriteLine(@"SOFTWARE\Microsoft\BizTalk Server\3.0\Administration\MgmtDBServer");
Console.WriteLine(@"SOFTWARE\Microsoft\BizTalk Server\3.0\Administration\MgmtDBName");
}
else
{
connection = "server=" + server + ";database=" + database +
";integrated security = true;";
}
return connection;
}
}
}
Hi Thiago,
Nice one, also noticed the GetBTSConnectionString() function, pretty slick 😉
I’ve been storing the name of the BTS Management DB name in the configuration for all of this time, it’s never too late to know this kind of thing though 😉
Thanks.
Thanks Bemberg! I got the GetBTSConnectionString idea from Carlos Medina’s blog and modified it a bit. Makes it pretty easy indeed when the connection is integrated security.
Honestly, for troubleshoointg purposes. I have found leaving tracking on and deleting the DTA every 6-10 hours works best.
Otherwise if something does go wrong. You are forced to try to “replicate the issue” and if it’s a 1 in 1000000 error, you will cause yourself greif by removing tracking all together. Furthermore, you hinder your companies ability to “promptly” resolve issues.
There are definately valid scenarios where message tracking needs to be enabled for referring back to the original message that went throught BizTalk. As I mentioned on the post our client had no need for message body tracking and the added processing it causes on the BizTalk environment and the simple application made it pretty easy to revert tracking back to its default values. I find it most companies only need troubleshooting if there is an exception thrown in which case the message is suspended (or routed to error handling solution) and they have the message contents there. It’s on a case by case basis though, I wouldn’t go enabling message body tracking enabled for everything just for the sake of it.
2 lines of your code is hidden, can you format it so that its not hidden behind the archive list ?
Done, hope it’s better now.