There are situations in which you might need to use or send a message in an orchestration within an exception handler block, but get a compiler error because the message was constructed in the associated scope outside the exception handler block.

For example, consider the following orchestration:

As you can see, I’m trying to send a message that was constructed outside the exception handler block. If an exception is raised before the message is constructed (for example in "Expression_1"), the orchestration will fail sending it.

Luckily, the compiler will warn us about this situation generating the following error:

error X2110: use of unconstructed message ‘myMessage’

In order to deal with this scenario, there is an operator in BizTalk Server 2004 that can be used to determine the outcome of a transactional scope, thus providing us the ability to know if the code within that scope was successfully executed or not.  This operator is called "succeeded()". This operator receives one parameter: the Transaction Identifier of the associated scope.

In our sample, in order to know when to send the message, we should construct the message in a transactional scope, and then ask for the execution result of that scope using the "succeeded()" operator in a Decide Shape, as shown in the following orchestration:

Note: The orchestration samples shown in this article were created in order to illustrate the usage of the "succeeded()" operator. Probably, they won’t have meaning in real scenarios.

Hope this to be useful!

When testing performance in stress situations, I've found really useful a query that returns the count of all orchestration instances grouped by state. For example: 

The query mentioned above is part of a paper that provides a set of useful T-SQL queries which can be used for operational management and troubleshooting.

This is a summary of the queries included:

1. Count of all Orchestration instances grouped by state:  This query gives you information about all orchestration instances in your system and groups them by state
2. Counts for all host queues: This query returns the table size for the three queues: WorkQ, SuspendedQ, and StateQ
3. Count for number of state messages grouped by instances: This query gives you a count of the number of state messages associated with each instance
4. Count of all active messages for a specific send port: “This query not only gives the count for how many messages are in the WorkQ for a given send port, but it will do a breakdown based upon the primary and secondary transport also. Even better, it will give you a count for the maximum number of retries any message is on.“
5. Last duration for our SQL Agent jobs: This query gives you information about when each job last ran and how long it took.

You could find these queries and additional details about the BizTalk Server internal databases here: http://home.comcast.net/~sdwoodgate/BizTalkServer2004AdvancedMessageBoxQueries.doc

BizTalk Server Development Center has recently released some papers and a Reference Implementation Sample that shows how to integrate BizTalk Server 2006, Windows Workflow Foundation, and Windows Communication Foundation in an enterprise solution.

This is an extract of what you can find there at http://msdn.microsoft.com/biztalk/:

Reference Application Pack for Retail
This white paper, along with the sample application, showcases integration using service orientation with BizTalk Server 2006, Windows Communication Foundation, and Microsoft Business Scorecard Manager.

Windows Workflow and BizTalk Server 2006 Code Sample
This sample demonstrates how to integrate Microsoft BizTalk Server 2006 and Windows Workflow Foundation through Web services.

BizTalk Server 2004 Service Pack 2 has been released. I strongly recommend you to read carefully the release notes and install the service pack in all your BizTalk Server 2004 environments.

Download it from here: http://www.microsoft.com/downloads/details.aspx?FamilyId=D20B4510-E5A6-4D7B-87A1-4BD52BDD57B8&displaylang=en

This is the List of bugs that are fixed in BizTalk Server 2004 Service Pack 2: http://support.microsoft.com/kb/924330/en-us

Hi everyone! Yesterday I faced an error when trying to compile a BTS project which was already developed on another machine. This project included an orchestration and some schemas and maps. The error was related to one of those maps:

“Exception Caught: Cannot use a prefix with an empty namespace”

I also received this error when trying to validate that mapping.

After doing some research I've found that this error was a well-known issue related to Biztalk Server Service Pack 1. The project compiled successfully on a Biztalk Server without SP1 installed, but compiled with this error after installing SP1.

There is a hotfix for this issue at Microsoft Support (KB 894177) [:)]. You could found that article here!

After the setup of the Enterprise Single Sign On, you could get the following error in the event log: 

The master secret has not been backed up. If you lose the master secret all the information stored in the SSO system will be lost permanently and your systems may fail to work correctly. Please use the SSO admin tools to back up your master secret.

This error occurs because the master secret has not been backed up after the installation.

In order to back up the master secret you should run the following command:

\Program Files\Common Files\Enterprise Single Sign-On> ssoconfig -backupsecret

When running this command, you should provide a password and a reminder,  then the master secret will be backed up to the specified file.

Example

C:\Program Files\Common Files\Enterprise Single Sign-On>ssoconfig -backupsecret C:\mastersecret_myBackup.bak

Password : ********
Confirm Password : ********
Password reminder : [myPasswordReminder]

The operation completed successfully.

I have a Biztalk Server 2004 orchestration which interacts with a Web Service using the SOAP adapter. Under stress situations, such as lots of concurrent running orchestrations calling the Web Service, the SOAP adapter reports exceptions of type “not enough threads in the thread pool” as shown below:

The adapter failed to transmit message going to send port “http://myVirtualDirectory/ws.asmx”. It will be retransmitted after the retry interval specified for this Send Port. Details: “There were not enough free threads in the ThreadPool object to complete the operation.”

After doing some research, I've found not only an explanation but also a workaround:

Explanation

“The error “not enough threads in the thread pool…” is due to a design flaw in CLR which was claimed to have been fixed in Whidbey. The reason for checking available threads before a request is pushed out is that the callback would take on another thread. So it tries to be smart. There is no guarantee a thread is available after the soap adapter checks for availability…“

Workaround

In order to deal with this error, I had to make some performance tuning to the BizTalk Server engine, modifying some parameters of adm_ServiceClass table of the Biztalk Management database (BiztalkMgmtDB).

The parameters to be modified are the HighWatermark and LowWatermark: “These two settings determine the outbound processing rate for messages. They represent high and medium stress-level thresholds, respectively. Both settings define the number of messages processed by BizTalk Server 2004, but not yet consumed by subscribers. When BizTalk Server processes more messages (not yet consumed) than specified by the HighWatermark threshold, it stops processing messages from the message box until the number of active messages decreases below the LowWatermark threshold”

I set these values to:

• LowWatermark: 10
• HighWatermark: 25 

There is a tool that allows you to change these settings easier. Download it from here!

Also I had to increase the maxWorkerThreads value (maximum number of worker threads per CPU) in the machine.config to 100:

• maxWorkerThreads: 100  

With these configuration changes the issue was gone and everything seems to work fine!

You could find more information about BizTalk Server 2004 Performance Characteristics here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/bts_2004wp/html/04d20926-20d2-4098-b701-52238a267eba.asp

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!