A number of you have contacted me in recent months to report that the BizTalk Orchestration Profiler and BizTalk Documenter didn't run on 64bit machines, this seems to have been down to compiler settings which I've now resolved.
I've uploaded a planned release for both tools to codeplex - if you've got a 64bit machine I'd appreciate it if you could install and test the tool to see if it works on your servers? Please let me know either way - I'll then make the releases as the default released versions once I've got validation.
You can find the releases at the following URLs:
http://www.codeplex.com/BizTalkDocumenter/Release/ProjectReleases.aspx?ReleaseId=8689
http://www.codeplex.com/BiztalkOrcProfiler/Release/ProjectReleases.aspx?ReleaseId=8688
I've done some tidying up across the entire codebase to make it easier to support and also reworked and re-released the Word output option for the BizTalk Documenter thus allowing Word documents to be generated as well as CHM files. Let me know if the Word output doesn't work as expected for you when compared to CHM output.
Please keep any feature suggestions coming...
I've managed to find somewhere to store the presentation deck I delivered yesteday and you can now download it from here. I've also added the slides I had to cut from the presentation to enable it to fit within the SOA & BPM conference breakout length - these cover the throttling semantics at a high level and detail some common symptoms you might see during performance testing and what you should look at to resolve them.
There's of course more detail in the book! Enjoy.
Microsoft has just made the first public announcement of “Oslo” at the SOA and BPM conference, at a high level “Oslo” is an overarching initiative across multiple products and Microsoft divisions, in fact the first release as announced today will be made up of BizTalk Server “6”, BizTalk Services “1”, Visual Studio “10”, System Center “5” and .NET Framework “4.0”. Therefore Oslo != Just BizTalk.
Official press release information can be found here and here along with a good overview by Directions on Microsoft which you can find here, but here’s my take for what’s it worth! J
Oslo is driven out of Connected Systems Division (CSD) which is the almagamtion of the BizTalk, WCF, WF, ASMX, MSMQ, .NET Remoting, etc. teams and has around 1000 people, Oslo as highlighted above is a huge program of work within CSD and across multiple divisions within Microsoft (AD, System Center, Developer Division, etc.). It's a huge investment.
Two key themes for Oslo were annouced during the keynote, Models (Making models a mainstream part of development) and Services (Extending services from the client to the cloud).
Those of you familiar with BizTalk Orchestration and Windows Workflow or even “Whitehorse” style designers such as those created using the DSL Tools or the Class Designer in VS are well versed with how a modelling tool works effectively enabling you to view and modify an underlying “thing” with an abstracted graphical language.
There has been lots of modelling attempts across the years across the industry; two things stand out for me as to why. Firstly the model is typically a representation at a point in time, you draw a nice pretty picture either for reference purposes or to then generate some physical representation like code.
Sometimes you get round-tripping which enables the model to be up-to-date but this becomes increasingly hard in most scenarios to the point of not being possible so invariably the model becomes out of date with the actual reality and therefore its value is minimal.
Secondly you have lots of “models” within a typical project, perhaps you have a business process modelled using BizTalk Orchestration, the physical datacenter modelled using the VS Team Architect tools and operational management within System Center. Nothing is shared between these models and therefore everyone has their own version of reality – often out of date and there’s no knowledge transfer between the various software development lifecycle roles.
In short, the modelling vision is a great thing but has a number of serious limitations today which limits its values to small isolated parts of your solution, imagine though having one model to describe your solution that could be used across your entire solution development lifecycle (Business Analyst, Developer, Tester, Operations, etc.).
This model of course needs to be rendered into different views for each of these stakeholders, a business analyst has a different “view” requirement to a developer for instance.
All of this is fine but don’t we end up with a stale description of a solution? Not in Oslo as the model is executed; therefore the model has to be up-to-date as its being used to execute the solution.
These models then have to “live somewhere”, firstly to make them broadly discoverable by all the stakeholders involved in the development process and secondly to enable them to be executed by some form of host. This is where the Metadata repository comes in which leverages SQL Server.
The viewing/editing experience will be provided through a new tool offering an “office like experience”, this will be able to interrogate the repository and retrieve/persist models. Precise technical detail of how all this hangs together isn’t available right now but more information will be available publically in due course.
So Modelling is a big focus for Oslo, basically taking the modelling concept but making it mainstream and used across the entire development lifecycle and thus connecting up all roles.
The next big focus for Oslo is around services and messaging; BizTalk today provides an incredibly powerful and flexible messaging platform through Adapters, Pipelines and the MessageBox. We have publish and subscribe, correlation, transformation all in the box.
Through the use of adapters we can easily integrate with a variety of technologies provided by different vendors running on different platforms but this typically speaking is all about integration/messaging within your corporate boundaries.
You can of course implement B2B scenarios where you can do cross business integration but any communication between B2B partners typically requires specific and dedicated communication links such as a leased line, VPN, SSL, etc. This is expensive and normally only implemented by the larger organisations.
Oslo is set to address this and more through the use of what Microsoft is calling a “Internet Service Bus”, imagine being able to connect two organisations together without requiring anything more than a internet connection, no need for leased lines, NAT traversal?
This in part is offered today through the BizTalk Labs preview of the BizTalk Connectivity Services, this offers the concept of a relay which can patch two applications together even if they’re behind their own respective firewalls and would normally have no way to directly communicate with each other.
The relay offers NAT traversal technologies and once it’s patched you together it can then completely step out of the communication path enabling you to communicate together. Now this might not see that useful on the surface but it opens up a whole new breed of solutions for the small-medium market but of course any size of user or customer.
In short the relay enables communicate between users and applications even though there is no direct communication link between the two – of course this NAT traversal solution has been down before in silos by software such as Groove and MSN Messenger. The key here is that the Connectivity Services are doing all the hard NAT stuff for you and the service is hosted by Microsoft in the cloud.
A Security Token Service (STS) is also supplied through the BizTalk Labs preview which offers an identity provider to enable you to offload identity and authentication functionality. Moving forward there is a commitment to provide workflow hosting.
All of these services are cloud hosted meaning that a Microsoft datacenter somewhere provides the hardware, resilience, software, etc. to expose these services, you don’t need to provision datacenter space, hardware, etc. but instead rely on Microsoft of another third party. How this will be charged for hasn’t been agreed at this time.
So combining models and these cloud based services is interesting as suddenly you can develop your solution using Oslo tools and then make a deployment-time decision to host within your datacenter or to host within the cloud. This is an interesting choice for organisations that currently maintain large datacenters and have to worry about monitoring, resilience and the like. It also opens up completely new possibilites about how users/services can be contacted regardless of where they are, as long as they have a internet connection and can "see" the cloud they can communicate regardless of what network infrastructure is in the way.
So, all of that aside – your probably thinking about BizTalk today? Should you continue to use it, will any new investment in BizTalk Orchestrations, Rules Engine, etc. be redundant in a few years time? There’s also a slightly scary statement in the Directions on Microsoft report that advises that you may wish to limit new development using BizTalk Server.
I don’t speak for the product team, but can say that enabling you to run BizTalk Server 2006 artefacts within the Oslo release will absolutely be supported – Microsoft can’t turn away from the significant investment that customers have made today and aren’t planning to.
So, in short carry on using Biz Talk. Oslo is a way away yet and there’s an incredible amount you can do with our technology stack today (BizTalk Server 2006 R2, Office 2007 Sharepoint, WCF, WF....)
That’s it for now, will provide some more thoughts and info as time goes on.
Thanks to everyone who came to my presentation today, I was humbled by the huge turnout! The presentation deck will be broadly shared to attendees which contains hyperlinks to all the tools showcased but in the meantime the links are below if you want to get started right away. I'll look to share the entire deck via the blog shortly if I'm allowed!
A new release of LoadGen has very recently been made available which I didn't mention today, this adds WCF support for injecting load amonst other things.
PerfMon Counter spreadsheet
http://media.wiley.com/product_ancillary/22/04700464/DOWNLOAD/Chapter9_Code.zip
Orchestration Profiler
http://www.codeplex.com/biztalkorcprofiler
BizTalk Documenter
http://www.codeplex.com/biztalkdocumenter
LoadGen 2007 (now includes WCF, Sharepoint 2007 support amongst others)
http://www.microsoft.com/downloads/info.aspx?na=22&p=1&SrcDisplayLang=en&SrcCategoryId=&SrcFamilyId=&u=%2fdownloads%2fdetails.aspx%3fFamilyID%3dc8af583f-7044-48db-b7b9-969072df1689%26DisplayLang%3den
Old version of LoadGen 2004 (recommend you use the 2007 release moving forward)
http://go.microsoft.com/fwlink/?LinkId=59841
BizUnit
http://www.codeplex.com/bizunit
I've just arrived in Seattle for the Microsoft SOA & BPM conference that kicks off on Tuesday 30th October in Seattle, I'm presenting a best-practice session on Wednesday afternoon titled "How everyone should test their BizTalk Server based solutions", it's a great deck with some compelling demos that went down very well at a internal technical conference earlier this year. If we can get BizTalk solutions tested properly - the world will be a much better place!
More as the week goes on, should be some interesting presentations....... In the meantime Sam Gentile has a great running commentary of the week.
Hi,
I've recently taken ownership of the source for the BizTalk Orchestration Profiler and BizTalk Documenter tools that Jason Birth originally developed, the documenter has worked fine with BizTalk Server 2006 but the Profiler was broken in a number of places. I have just finished a new build of the Profiler which now works with 2006 and fixed a few other niggles, both tools are now available and I'm open to feature suggestions for both tools moving forward.
If you haven't seen or used the tools before then do take a look - they are invaluable in many circumstances and I for one use them one way or another on every BizTalk engagement, the Profiler is here: http://www.codeplex.com/BizTalkOrcProfiler and the Documenter is here: http://www.codeplex.com/BizTalkDocumenter
Information on both tools is copy/pasted below from the respective CodePlex sites, enjoy!
BizTalk Orchestration Profiler
Creates CHM report files illustrating the level of coverage for specified BizTalk orchestrations. This tool can be run to gain a consolidated view of orchestration tracking data for a specified period of time to help developers get an idea of how their orchestrations are being processed and how much coverage they are getting in their testing. In addition to simple coverage information the data presented helps to identify latency and code path exceptions by highlighting long running and error prone orchestration shapes which is key to effective performance testing.
The image below shows a sample of the coverage summary, at a glance you can see the percentage of overall coverage acheived upon an individual orchestration, if all of the shapes are touched as part of your orchestration then you will acheive 100% coverage, common reasons for not covering all shapes with an orchestration are not running tests that stress the error paths of your solution. This coverage summary also provides you metrics around execution duration of your orchestration easily identifying orchestrations that take a long time to execute.
The image below shows the orchestration coverage in detail, shapes highlighted in green have been executed as part of your last test pass and any shapes not executed will be highlighted in red. This enables you to easily understand what parts of your solution have been tested and which parts have not and adjust your testing as necessary.
As part of the profiler report you can see the "Top 10 Least Successsfull" shapes and the "Top 10 Longest Running" shapes, understanding where time is being spent inside your orchestration is key to effective performance testing and has been proven on a number of instances to pinpoint poor orchestration design and coding which when resolved has dramatically increased overall performance. The key is to understanding exactly where time is being spent and this tool offers a no-code view into your running system.
BizTalk Documenter
Creates compiled help files for a given BTS 2006 installation. This tool can be run on an ad-hoc basis using the UI or from the command line as a post build/deploy task to create a compiled help file describing a BTS 2006 installation. It will compile: BTS Host configuration, Send/Receive port configuration, Orchestration diagrams, Schema and Map content, Pipeline process flow, Adapter configuration, Rule engine vocabularies and policies, More… and publish them as compiled help files. Optionally you can embed custom HTML content and custom descriptions for all BTS artifacts to produce a more customized look and feel to the CHM output
This tool can be run on an ad-hoc basis using the UI or from the command line as a post build/deploy task to create a compiled help file describing a BTS 2K4 installation. It will compile:
• BTS Host configuration
• Send/Receive port configuration
• Orchestration diagrams complete with any custom code
• Schema and Map content
• Pipeline process flow
• Adapter configuration
• Rule engine vocabularies and policies
• More…
and publish them as compiled help files or Word 2003 XML. Optionally you can embed custom HTML content and custom descriptions for all BTS artifacts to produce a more customized look and feel to the CHM output.
The screenshow below shows some of the information collected about an Orchestration, you can see what variables, maps, messages, ports, correlation sets, etc. that are used by a given Orchestration.
The screenshot below shows further orchestration information which is collected, in this case we can see all of the inline code written by the developer for the orchestration, useful for code reviews and understanding a solution.
Long overdue but I've finally got around to finishing up the latest release (1.1) of the GenerateTypedBamApi tool. You can find the new version here, if your not familar with the tool read on!
The GenerateTypedBamApi command line tool enables you to take a BAM Observation model represented as a Excel Spreadsheet and generate a set of strongly typed C# classes which you can then use to create and populate BAM Activities.
The native BAM API is loosely typed and therefore requires Activity Names and Activity Items to be supplied as string literals, this can be brittle especially as the observation model evolves over time and any typos, etc. will lead to runtime errors instead of compile time errors.
A strongly typed class is created for each Activity with properties for each Activity Item along with helper methods to write Activity Items to an Activity, Add References, Custom References (e.g. Message Bodies) and Continuation.
This tool uses a XSLT transform to turn the XML representing the BAM Observation Model into C# code.
For further information on how to use BAM and why you might want to use a BAM API approach over the in-bult graphical Tracking Profile Editor please Chapter 6 of my BizTalk Book: Professional BizTalk Server 2006: http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470046422.html
Example
Consider the code whoen below which demonstates the creation of a BAM Activity (called Itinerary in this case), it populates a number of Activity Items, adds a reference to another Activity and finally adds a custom reference of a message body.
As you can see from the code many string literals representing the Activity Name and Activity Items are required throughout the code, any mistakes will cause runtime errors which can be frustrating especially when you have to undeploy and redeploy your BizTalk solution. Also, if you have a medium to large scale project then you will end up with many Activities and Activity Items which can require many lines of code to be manually created each time.
string ItineraryActivityID = System.Guid.NewGuid().ToString();
DirectEventStream des = new DirectEventStream("Integrated Security=SSPI;Data Source=.;Initial Catalog=BAMPrimaryImport", 1);
des.BeginActivity("Itinerary", ItineraryActivityID);
des.UpdateActivity("Itinerary", ItineraryActivityID, "Received", System.DateTime.Now,
"Customer Name","Darren Jefford","County","Wiltshire","Total Itinerary Price",1285);
des.AddReference("Itinerary", ItineraryActivityID, "Activity", "Flight", flightActivityID);
des.AddReference("Itinerary", ItineraryActivityID, "MsgBody", "MessageBody", System.DateTime.Now.ToString(), myXmlMessageBody);
des.EndActivity("Itinerary",ItineraryActivityID);
In contrast consider the code shown below which uses the Interary C# class created by this tool, each Activity Item can be set using class properties which are strongly typed and therefore checked at compile time instead of runtime. Simplified wrappers are provided around operations such as adding references and the ActivityID is stored internally once you've constructed the Itinerary class which saves you having to pass it each and every time. In short this code is far simpler and easier to maintain especially as Activities evolve during your development lifecycle, also for medium to large projects this code generation approach can save you having to write hundreds to thousands of lines of code!
// Create a new Itinerary activity class, passing a GUID as the ActivityID
DirectESApi.Itinerary itin = new DirectESApi.Itinerary( System.Guid.NewGuid().ToString() );
// Begin the activity
itin.BeginItineraryActivity();
// Set activity items
itin.Received = System.DateTime.Now;
itin.CustomerName = "Darren Jefford";
itin.County = "Wiltshire";
itin.TotalItineraryPrice = 1285.00M;
// Commit these changes to the database;
itin.CommitItineraryActivity();
// Add a link between this Itinerary activity and another flight activity that already exists
itin.AddReferenceToAnotherActivity(DirectESApi.Activities.Flight, flightActivityID);
// Add a message body to this activity (or any other data you require)
itin.AddCustomReference("MsgBody", "MessageBody", System.DateTime.Now.ToString(), myXmlMessageBody);
// End the Activity
itin.EndItineraryActivity();
I arrived in Orlando yesterday after a long old flight from London and should make the Party with Palermo tonight which looks like it'll be fun but as I'm presenting tomorrow it'll be a quiet night!
My two sessions are shown below, the second session being a very informal chalk/talk style session without any slides so if you want to know more about BizTalk Performance & Scalablity testing or have some questions, come along!
A book signing has been organised at the TechEd bookstore following my session on Monday, come along between 1815 and 1845 and Ewan and I will be signing copies!
My sessions this week are:
SOA306 - Building an Enterprise-Wide Instrumentation Solution Using the Microsoft BizTalk BAM Infrastructure
Monday 4th June: 1645 to 1800
Track(s): SOA and Web Services
Level: 300
Speaker(s): Darren Jefford
Business Activity Monitoring (BAM) is a powerful feature of BizTalk Server and is often marketed as allowing "the business" to understand what is happening within your BizTalk solution. BAM does this really well, but it can in fact be used in a variety of other ways which can deliver huge value to customers and address a number of issues they have with BizTalk based solutions and non-BizTalk based solutions.
In this session, we cover some of the fundamentals of BAM and detail how you can utilize BAM to collect a variety of information and produce a "tracking portal" which you can use to support your application, perform manual repair of messages, and generally observe your solution.
We also show how BAM is not just for BizTalk solutions and how it can be used to produce an enterprise-wide instrumentation solution that is highly scalable and flexible; we touch on the new Windows Workflow Foundation and Windows Communication Foundation (WCF) BAM Interceptor technology that enables data to be collected from Workflows and WCF services enabling a true end-to-end instrumentation solution.
SOA13-TLC - Microsoft BizTalk Performance Testing
Thursday 7th June: 1630 to 1745
Track(s): SOA and Web Services
Level: 400
Speaker(s): Darren Jefford
Testing is a critical area for any solution and BizTalk is no exception. In this session, we start by covering the foundations that you need to put into place before beginning any performance testing, covering the most common environment problems that cause problems during testing and highlighting a number of tools to make testing easier including BizUnit and LoadGen.
Then, we cover how you should monitor your solution during testing; highlighting the key performance counters that should be monitored and explaining how throttling works. We finish by covering a number of common symptoms that you're likely to experience during testing; we explain why these occur, how to spot them, and more importantly how to resolve them.
After what seems like a huge delay the usual UK retailers such as Amazon and Computer Manuals now have stock of the book! From what I've heard pre-orders have already started to drop through letter-boxes.
Enjoy, and please remember to put a review on Amazon if you get the chance!
For those of you going to TechEd in two weeks time, Ewan and I will be taking part in a book signing on Monday the 4th June between 6:15pm to 6:45pm at the TechEd book store following my breakout session.
Another quick update, it seems that stores in the US now have stock and are shipping. Both Amazon.com and BarnesAndNoble are reporting stock! The UK should follow very shortly, 7 days seemed to be the difference with the Team System book
I knocked out a brain-dump of some BAM best practices this morning for a colleague, it seems like a good thing to share more broadly. It's a starter for 10 and I'll refine it over time I'm sure, the book covers all of these things in far more detail as you'd expect :)
• Avoid continuation where you can as it incurs performance overhead, it’s not the end of the world if you were to use continuation but just remember the overhead. The rule of thumb seems to be that up to 2 continuations is OK any more and you should create new activities and link them together using references.
• You must always use continuation if you are writing data to an activity over time and using an eventstream other than the DirectEventStream.
• If you are using continuation you must always call EndActivity passing the original ActivityID once you have enabled continuation, otherwise it can lead to orphaned activities that don’t move from Active to Completed. In short EndActivity must be called for every ActivityID used throughout the lifetime of an Activity.
es.BeginActivity(“MyActivity”, “ActivityID_1” );
...
es.UpdateActivity(“MyActivity”,”ActivityID_1”,”Name”,”Darren”);
es.EnableContinuation(“MyActivity”,”ActivityID_1”,”ActivityID_2”);
es.EndActivity(“MyActivity”,”ActivityID_1”);
....
es.UpdateActivity(“MyActivity”,”ActivityID_2”,”Age”,”99”);
es.EndActivity(“MyActivity”,”ActivityID_2”);
• Run SQL queries against the SQL Views not the tables otherwise you may not retrieve all of the data due to table partioning occuring under the covers through the use of the Data Maintenance (DM) job
• Schedule the DM_<ActivityName> SSIS job to ensure your Activity tables are swapped out for empty ones to maintain insertion speed
• Use OrchestrationEventStream/MessagingEventStream wherever possible as this will keep the Bam data transactionally consistent with the execution of the orchestration or message in that if the orchestration rolls back the BAM data will be as well. You also benefit from being able to piggy back the orchestration persistence database roundtrip or interchange commit.
• Ensure the tracking host is running if your using a EventStream other then DirectEventStream, the host responsible for tracking can be configured through the BizTalk Administration Console. This defaults to BizTalkServerApplication so ensure this host is started otherwise data will not appear in the BAMPrimaryImport database.
• If your using an EventStream other than DirectEventStream then BAM data is copied out of the BizTalkMessageBox using TDDS, you can see the data pending via the Tracking Data Size perfmon counter, although if you have global tracking enabled this will also include tracking data.
• BAM can store up to 1MB of data through the AddReference method on the eventstream, a great well-pefoming solution for message-bodies which enables the storage of message bodies alongside the data that describes how it was processed.
I'm pleased to announce that I'll be presenting two sessions at TechEd which is being held at Orlando between Monday 4th June and Friday 8th June! The first is a breakout session which covers BAM and demonstrates some real-world examples of how we've put BAM to great use and how it has a place in almost every BizTalk solution, the second is a chalk-talk covering BizTalk performance testing.
Ewan Fairweather (author of the Administration chapter in my book) will also be presenting a breakout session titled "SOA310 - Best Practices and Customer Evidence on Enterprise Ready BizTalk Implementations"
The session abstracts are shown below for reference, and it looks like a book signing will be organised during the week for those of you attending that want to get a signed copy! See you there!
SOA306 - Building an Enterprise-Wide Instrumentation Solution Using the Microsoft BizTalk BAM Infrastructure
Track(s): SOA and Web Services
Level: 300
Speaker(s): Darren Jefford
Business Activity Monitoring (BAM) is a powerful feature of BizTalk Server and is often marketed as allowing "the business" to understand what is happening within your BizTalk solution. BAM does this really well, but it can in fact be used in a variety of other ways which can deliver huge value to customers and address a number of issues they have with BizTalk based solutions and non-BizTalk based solutions.
In this session, we cover some of the fundamentals of BAM and detail how you can utilize BAM to collect a variety of information and produce a "tracking portal" which you can use to support your application, perform manual repair of messages, and generally observe your solution.
We also show how BAM is not just for BizTalk solutions and how it can be used to produce an enterprise-wide instrumentation solution that is highly scalable and flexible; we touch on the new Windows Workflow Foundation and Windows Communication Foundation (WCF) BAM Interceptor technology that enables data to be collected from Workflows and WCF services enabling a true end-to-end instrumentation solution.
SOA13-TLC - Microsoft BizTalk Performance Testing
Track(s): SOA and Web Services
Level: 400
Speaker(s): Darren Jefford
Testing is a critical area for any solution and BizTalk is no exception. In this session, we start by covering the foundations that you need to put into place before beginning any performance testing, covering the most common environment problems that cause problems during testing and highlighting a number of tools to make testing easier including BizUnit and LoadGen.
Then, we cover how you should monitor your solution during testing; highlighting the key performance counters that should be monitored and explaining how throttling works. We finish by covering a number of common symptoms that you're likely to experience during testing; we explain why these occur, how to spot them, and more importantly how to resolve them.
I've just had an update from Wiley and the book arrived into their warehouse last Friday (20th April) and it started physically shipping to stores yesterday (Monday 23rd April) so if you've pre-ordered expect it to arrive real soon! I hope you enjoy it!
Woo Hoo!!
For developer level tracing the tracing classes held within the System.Diagnostics namespace are often used along with the Windows Sysinternals DebugView tool. Tracing events are written to OutputDebugString via the DefaultTraceListener trace listener.
This listener writes output to OutputDebugString (which DebugView can monitor), and a managed debugger (if one is attached). In addition the DefaultTraceListener trace listener is responsible for popping up and dealing with the managed assert message box. You can disable the "default" DefaultTraceListener in your application’s config file as required.
This approach to tracing works extremely well and is something I use myself a lot, but you should be aware of the associated performance overhead. DebugView effectively acts as a debugger and hooks the OUTPUT_DEBUG_STRING_EVENT event, as a result your application (a BizTalk process perhaps) will experience a performance impact as the application threads will be suspended whilst the debug information is output, effectively serializing your application. Therefore if you have many Orchestrations in-flight (or multiple threads if your not using BizTalk) they will all be side-affected if DebugView is started and performance will therefore be affected.
It's worth noting that if the DebugView tool is not started (and therefore there are no subscribers to the information) the performance impact is negligible and shouldn't in my experience be something to worry about, therefore do not be afraid to output information that you feel will be useful.
Either way you should ensure that your tracing code is implemented such that it can be disabled to reduce the performance overhead, typically you will need the ability to enable it at run-time. When carrying out performance testing you will most likely want to disable tracing, although gaining an understanding of the overhead is also valuable.
In my view the performance hit associated with software tracing is outweighed by the ability to diagnose run-time issues in a non-intrusive manner. Most Microsoft products, including BizTalk Server, rely heavily on software tracing which the product group leverage to diagnose customer issues off-line. Just be aware that running DebugView during performance testing or on a live server is very likely to significantly impact performance! I'm not saying not to use it, Please Do! It makes everyone's life easier but just be aware of the performance impact when your running those tests and in live.
Roll on the mighty ETW TraceListener planned for Visual Studio “Orcas”, kernel model ultra-fast tracing from managed code! ETW has been available for a while but has been pretty hard to leverage from managed code. It’s worth nothing that BizTalk itself uses ETW heavily to provide extremely rich internal “developer level” tracing which we can use to diagnose problems at customer sites.
Thanks to Jon Fancey for highlighting this during the review stage of the book, he experienced a solution being seriously impacted when DebugView was left running on a live server, and to Matt Ellis (BCL) for adding some detail around the DefaultTraceListener.
I’ve used the same base VPC for my various BizTalk Server 2006 images over the last few years, this has worked fine apart from a few annoying bugs that of course plagued every single instance of a VPC using it, of course I never really spent the time to iron them out so suffer from them every now and again :-(
All are most certainly down to me not having exactly the right bits installed or not having the configuration quite right. One annoying problem was the Pivot Table view on the BAM Portal refusing to work by coming up with the following unhelpful error:
“The query could not be processed: Cannot connect to the server 'DARRENJBTS06'. The server is either not started or too busy.”
Over the years I’ve tried just about everything to fix it: Configuration, Security, Service Packs,etc. but have never managed to solve it until now - after some digging internally it seems that my base VPC was missing Version 9.0 of the Analysis Services OLE DB Provider, installing this resolved the issue straight away, the update is listed on this page along with some other updates.
Hope it helps!