Microsoft BRE: Fact Identity in the Microsoft Rules Engine, or how the author chased a non-existant bug

by | Apr 4, 2007 | BizTalk Community Blogs via Syndication

I recently had reason to revisit the exact mechanisms Microsoft use when you assert facts to the Microsoft Rules Engine.   I was discussing stuff on-line with a fellow rules enthusiast when a terrible thought occurred to me.   Can the MS BRE always uniquely identify each different fact, or is there a chance that sometimes it might confuse two facts with each other?


For a couple of days, I was convinced that I had stumbled on a significant bug.   Indeed, at one point, I thought there was such a serious problem that I would have to recommend to my company that we desist from any further use of Microsoft’s rules engine.   Melodramatic, huh!    Fortunately, after a bit more research, I discovered that I was quite wrong.   The MS BRE does not suffer from a terminal flaw and can be trusted to always distinguish correctly between all your facts.   It’s worth recording my suspicions, mistakes and eventual enlightenment.   There is something useful to learn, here, about the inner workings of the engine, and also about Microsoft’s implementation of the Hashtable class in .NET.   


Read more at http://geekswithblogs.net/cyoung/articles/110852.aspx

VSTS Unit Tests in your BizTalk Solution…

by | Apr 4, 2007 | BizTalk Community Blogs via Syndication

We were having a problem with a BizTalk assembly (containing only maps) having a “project”
reference to a standard C# library.  As soon as the project reference was added,
we were unable to open the maps – errors along the lines of “unable to
open source schema” and “unexpected error encountered…vsee\internal\inc\vscomptr.inl”. 
See here for
a good forum discussion on the issue that we came across.

It turns out this issue crops up if you have a VSTS unit testing project in the same
solution…How is that for a strange product interaction?  Possible workarounds
include removing the unit testing project (and putting it in a separate solution)
or using a file reference instead of a project reference.  (If you go the
latter route, go to the properties of your solution and set up the project build dependencies
manually to account for this!)

We opted for file references rather than removing our unit test assembly, at least
for the time being.  Hopefully this will be addressed soon…

VSTS Unit Tests in your BizTalk Solution…

by | Apr 4, 2007 | BizTalk Community Blogs via Syndication

We were having a problem with a BizTalk assembly (containing only maps) having a “project”
reference to a standard C# library.  As soon as the project reference was added,
we were unable to open the maps – errors along the lines of “unable to
open source schema” and “unexpected error encountered…vsee\internal\inc\vscomptr.inl”. 
See here for
a good forum discussion on the issue that we came across.

It turns out this issue crops up if you have a VSTS unit testing project in the same
solution…How is that for a strange product interaction?  Possible workarounds
include removing the unit testing project (and putting it in a separate solution)
or using a file reference instead of a project reference.  (If you go the
latter route, go to the properties of your solution and set up the project build dependencies
manually to account for this!)

We opted for file references rather than removing our unit test assembly, at least
for the time being.  Hopefully this will be addressed soon…

WCF LOB Adapter!!!

by | Apr 4, 2007 | BizTalk Community Blogs via Syndication

These days, Microsoft is busy veiling out lots of LOB Adapters for BizTalk Server 2006 R2. One of them , which interests me most is WCF LOB Adapter. We can get all latest updates and news on this and other adapters from Sonu Arora (Program Manager, Microsoft).
Check for more information on this here
I know for […]

Watch out: DebugView (OutputDebugString) & Performance

by | Apr 3, 2007 | BizTalk Community Blogs via Syndication

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.

BAM: PivotTables not working on the BAM Portal

by | Apr 3, 2007 | BizTalk Community Blogs via Syndication

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!