Debugging XSLT Stylesheet with Custom Extension Objects from Within Visual Studio

This blog post was very useful today!

A Technical Perspective

When developping complex maps with the BizTalk Mapper, you sometimes find yourself in a situation where you need to debug the underlying logic of the associated XML stylesheet.

In situations like these, it is customary to have Visual Studio generate an XSLT file from the BizTalk map, and use Visual Studio’s builtin support for debugging XSLT. This allows you to put breakpoints, inspect the content of variables and precisely monitor the transformation step by step.

Custom Extension Objects

There are two cases, however, that prevent you from debugging the underlying XSLT from within Visual Studio :

The first case involves the use of the various database functoids, for instance the cross-reference GetCommonValue, GetCommonID, GetApplicationValue and GetApplicationID functoids. These, are implemented in terms of external functions, in a separate assembly, that is itself referenced from the generated map.

The second case involves the use of the Scripting functoid to call an…

View original post 765 more words

Caching Values from the SSO Configuration Store

Most of us who have been using BizTalk Server for a while use the SSO database as a secure store of configuration values. Microsoft made this much easier a few years ago when they released the SSO Configuration Application MMC Snap-In. Better yet, it comes with a sample class you can use to implement in your applications. This frees developers from having to add AppConfig segments to the BizTalk config file. In multi-server deployments, this gets really nasty because you have to change the config on every application server. SSO is by default available to the cluster. So, configuration changes are automatically made available to the entire BizTalk Group.

One common use of the SSO Config Store is a repository for database connection strings required by BizTalk maps performing database look-ups. A script component can call out to a class which wraps the client code that ships with the MMC Snap-In. Or you could use the BizTalk Mapper Extensions created by Sandro Pereira, which ship with a custom functoid to SSO config.

However, there is a problem. When you use the tool in a looping BizTalk map, it will make a call to the SSO database to retrieve config values for each element in your loop. In the case of a connection string, you are making unnecessary calls to SSO. Just open up the SQL Server Profiler, and you can watch all of the extra calls to the SSO database. With large messages, I have seen this severely degrade performance.

I have opted for creating a simple wrapper method, which uses a module-level dictionary object to cache configuration values needed by the map. This reduces the number of calls to the SSO database to one per config value. As you might expect, this significantly increases performance with even moderately large messages. The durability of the cache is only for the life of a single instance of the map. So, if you want something even more durable, you would need to rely on something like the AppFabric Cache.

Here is some sample code for caching values from the SSO config store…

private Dictionary<string, string> _ssoConfigurationValues = new Dictionary<string, string>();

public string GetSSOConfiguration(string appName, string propName)
string key = string.Concat(appName, propName);
string value = string.Empty;

if (_ssoConfigurationValues.ContainsKey(key))
return _ssoConfigurationValues[key];
value = SSO.Utility.SSOClientHelper.Read(appName, propName);
_ssoConfigurationValues.Add(key, value);
return value;

catch (Exception ex)
throw new ApplicationException("GetSSOConfiguration function call read failed", ex);

Insert XML Elements with the BizTalk Rules Engine

I have a case where I need to validate an incoming XML message and generate an aggregated XML message containing all validation failures. The base functionality of the BRE does not allow this kind of message manipulation – adding new elements (nodes) to messages and then setting the value.

My good friend Bing to the rescue!

This blog post gives a good walkthrough of doing exactly what I needed to do using the Microsoft.RuleEngine.XMLHelper class. Pay close attention to the Windows Registry setting at the end of the post.

This MSDN blog had a very good sample BRE Policy that I used to see a concrete example. Download the .exe and extract it.

This MSDN document details the Windows Registry setting that I mentioned previously. The function is to allow the BRE to use .NET helper methods as static objects, rather than requiring an instance.

These three sources combined gave me the complete solution. It works like a charm, and I did not have to write my own custom .NET helper class to do the XML element insertion.

Good times!

Handling “OR” Operators in the BizTalk Rules Engine

Once again, here we are talking about the BRE!

I have a set of rules that utilize the OR operator. I found a very, very interesting article describing in detail how the BRE handles the OR operator.

Cliff Notes:

  • OR is not handled like procedural languages, such as C# – there is no short-circuiting. All elements of the OR condition are evaluated, and therefore each submits a separate match to the Agenda to be followed by the BRE
  • In the BRE (or any Rete engine) OR is much more analogous to SQL. Since each member of an OR condition results in its own “record” per-se, it can be loosely understood as a SQL using the UNION ALL clause, having a separate SQL statement for each member of the OR condition
  • BizTalk BRE performs a de-duplication after processing rules that keeps the multiple Rete results from rules using OR from being added to the processing Agenda. This mitigates some of the, “What the…” you felt when reading bullet one above!
  • If you purposely want separate Agenda items to be processed, you can force the BRE to do this by creating a separate rule for each member of your OR condition (i.e. don’t use OR in your rules, create multiple rules instead).

Retrieve Suspended Messages from BizTalk Server

A client was complaining that during an outage of a downstream system, they would experience dozens of suspended messages in BizTalk Server (or more). They asked if there was a way to retrieve all of the suspended messages, rather than having to go through the slow and tedious process of saving them out of the BTS Admin Console.

PowerShell to the rescue!

This blog post has the solution:


BizTalk Rules Engine – Christmas Come Early!!!

As my recent blogging indicates, I’ve been working with rules BRE policies over the last few days. I’ve had to do some interesting things with vocabularies, as you might have surmised from my last couple of posts. What this meant was I would have to make a vocabulary change, publish it, and test it to see if it works.

Well, I don’t want a slew of vocabulary versions hanging out there, and when my development is complete I want all of my rules policies to use my latest-and-greatest vocabulary version. Doing this manually, with even a handful of meaningful rules, is just plain painful! So, a quick Bing gave me the best gift a BRE developer in this situation could ever ask for!

Vocabulary Updater Tool

This handy little command-line tool will take whatever policy you point it at, make a new version of the policy, and update it to the latest version of the vocabularies it depends upon. It works quite well and saved me from trying to bribe my children into the sweatshop kind of labor it felt like doing this by hand!

Updating multiple nodes with different parents and hierarchical levels using the BizTalk BRE

More tricks on handling hierarchical XML in the BRE…these techniques need to be better documented on MSDN!

BizTalk Messages

Oops, this must be the longest and worst blog post title you have ever seen. Let’s quickly make clear what I mean:

Recently I needed to update multiple elements using a single rule in the Business Rule Engine (BRE). To most BizTalkers this is nothing special. The thing that complicated this particular scenario was that the elements to update where in different hierarchical levels within the xml instance and thus had different parent nodes.

See the following XML and corresponding XSD instance for an example of this scenario:

<ns0:Customer xmlns:ns0=http://Samples.BRE.Customer>

View original post 1,068 more words