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:
http://www.codeplex.com/BiztalkOrcProfiler/Release/ProjectReleases.aspx?ReleaseId=6375
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:
Microsoft.Sdc.OrchestrationProfiler.exe.config
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:
Microsoft.Sdc.OrchestrationProfiler.exe.config
And change the path to the location where the hhc.exe file is locate don your computer, on mine it is at:
<appSettings>
<add key="HelpCompilerLocation" value="C:\Program Files\HTML Help Workshop\hhc.exe" />
<add key="ShowHotSpots" value="0" />
</appSettings>
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.
Cheers
- Uncategorized
Romiko Derbynew 