I’ve been busy trying to get the MSMQT Adapter working in a load balancing situation.

After doing some tests, I’ve found that when using DIRECT=TCP:[IPNumber]\PRIVATE$\queueName, messages were sent successfully, but when using DIRECT=OS:[MachineName]\PRIVATE$\queueName messages were rejected and unacknowledgements were received.

The cause for this situation was that MSMQT Adapter was originally installed using the local machine name instead of using the virtual address. I’ve solved this problem by changing the value of this registry key HKLM\SYSTEM\CurrentControlSet\Services\BTSSvc.3.0\MessageQueuing\MsmqtMachineName. Setting this value to the name of your load balancer will get rid of the naming issues!

In order to globally enable or disable the tracking feature on your Biztalk Server you could use the “WMI GlobalTrackingOption”.

Basically what you should do is use a query to retrieve a “MicrosoftBizTalkServer” WMI object and then set the value of this property as shown below:

‘Turning tracking on

objInst.GlobalTrackingOption = 1

‘Commit changes

objInst.Put_(1)

‘Turning tracking off

objInst.GlobalTrackingOption = 0

‘Commit changes

objInst.Put_(1)

You could find this script at GotDotNet “BizTalk Server 2006 Scripts” (it works also for Microsoft Biztalk Server 2004).

If you want to check if tracking is turned on or off you could do that by querying the Management database (BizTalkMgmtDb) in SQL Server, return all rows on table “adm_Group” and check GlobalTrackingOption column value.

USE BizTalkMgmtDb

GO

SELECT GlobalTrackingOption , * FROM adm_Group

Hi everyone! Today I’m going to talk about Biztalk Server MSMQT Adapter and some performance issues I’ve faced under stress situations.

Before that, a little MSMQT introduction: MSMQT is different from MSMQ. MSMQT is a Biztalk Server 2004 Adapter that was built to get around the 4MB MSMQ limit which was a pain in previous versions of BTS. MSMQT listens on the standard MSMQ port for messages and ensures they are delivered straight to the MessageBox.

Now let’s see what happens in stress situations. I’ve faced a scenario where about 60 messages per second were sent to a simple MSMQT queue, and the result was very low processing average. I did some analysis on that situation and found that the cause for that poor performance was because those messages were received very slowly in the message box, one after another. After doing some research I’ve found that MSMQT process messages in only one thread per queue.

So, the solution to our problem in order to speed up the processing was to create multiple queues. I created a single Receive Port with multiple MSMQT Receive Locations and changed our application to send one message to each queue instead of sending all messages to a single queue. The results were amazing, we really improved processing times and achieved the average we were looking for!

Hi everyone! It’s been a lot since my last post!

Today I want to share with you my experience about a training course I attended a month ago. I can say that I’m a “Certified ScrumMaster” now, and I’m very proud!

The course was really excellent! I learnt a lot and settled concepts about Scrum. It was a pleasure to be part of it!

You could find information about this course here: CSM course

Here are some great posts from Tobias Mayer, our trainer during the course:

• 
  
  The Argentina Scrum Adventure - Day 1
  
  
• 
  
  The Argentina Scrum Adventure - Day 2
  
  
• 
  
  The Argentina Scrum Adventure - Day 3

If you ever have a chance to attend a course like this, please don’t hesitate about it!