BizTalk 2006: Analyzing Orchestrations Execution Statistics

Hi Folks,

When you have developed an Orchestration with different possible routes and branches, it might be useful to know which branches are executing the most. I certainly dislike Orchestrations but for this solution, I had to use one due to legacy system design L, so I got a good excuse this time round!

I am using an orchestration here that calls many other orchestrations (BAD PRACTICE, so always avoid it if possible).

You can use a tool called

BizTalk Server 2006 Orchestration Profiler v1.1.1

Download the Code from:

If you running it on 64 bit machine, change the config of the file for the program files directory!

C:\Program Files\Microsoft Services\BizTalk 2006 Orchestration Profiler

In 64 bit it is C:\Program Files (x86) Microsoft Services\BizTalk 2006 Orchestration Profiler


So just fix the configuration file path:



Ok, so now we ready to analyze the orchestration. Go to the Start Menu to start the program

Click List Orchestrations

Click the Orchestrations you want to profile. Then Click generate report.


If you get this error:



Then you need to go to the config file I spoke about:



And change the path to the location where the hhc.exe file is locate don your computer, on mine it is at:


<add key="HelpCompilerLocation" value="C:\Program Files\HTML Help Workshop\hhc.exe" />

<add key="ShowHotSpots" value="0" />


The HHC.EXE file is used to create a chm file which is windows help file, nice to use to page through and stuff like that.

You can download it and install it at:



I chose to install it in the same location as the default location in the config fiel above J


After installing this etc, I went back the program and generated the report for my orchestration:

It created a report on my c:\ BizTalk Orchestration Profile Report.chm




So from the above you can see that this particular orchestration catches general exceptions and not other types of exceptions, so I know from the web service errors that general exceptions are being thrown in 100% of the cases. I use this example as a example where I ran a test cycle on 200 records and wanted to know where in my orchestration the 38 records out of the 200 failed, I wanted to know if it was a combination of different type of errors, to get an idea of what error handling the external web service may need, since the external web service I call, always returns a False or True (Not a cool way to do things, always develop web services to give decent error messages!)

So from here, I can see the general flow of messages and what exception types occur and make additional improvements to the design.

Also, I can see what takes long.

Also which shapes are a loser.

Hope you also get a chance to profile your orchestrations and see how they are working!

Good Luck, and remember, avoid orchestrations when you can, they the easy way out and can cause an overhead if used in the incorrect manner. I have seen on many occasions people using them in an Object Orientated Manner, not good, the orchestration in this example is a good case to go by, it calles other orchestrations that should actually be treated as objects not orchestrations.


  • Uncategorized

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s