When testing policies that use a lot of database facts in Rule Composer (or .NET components that access database) you may not want to hardcode connection strings into BRE as constants. There's a better place to keep them - the BRC config file. Since there's no such file we can make one. Go to the Biztalk installation folder and create file named Microsoft.RuleComposer.exe.config. Simply put in any configuration settings you want as in regular .net config file, for example:
<configuration>
<connectionStrings>
<add name="MyDbAlias" connectionString="Data Source=MyDbHost;Initial Catalog=MyDbName;Integrated Security=SSPI" />
</connectionStrings>
</configuration>
Then simple helper method that returns connection string can be exposed as a .NET fact and reused in policies. With the example above line below will work (.NET 2.0):
return ConfigurationManager
.ConnectionStrings[dbName].ConnectionString;
I prefer not to use bare database facts in BRC at all due to limiting functionality and unneeded exposure of underlying data sources. I found wrapping database facts into .NET components cleaner and brings in more benefits than drawbacks:
- gives access to more powerful and optimized queries using stored procs;
- enables using data access helpers and enterprise libraries (like EntLib) throughout the cycle starting from vocabulary/rules creation;
- makes good case for unit testing (in line with other .NET facts);
- frees from the responsibility of declaring DataConnection variables in each orchestration, one fact source host variable of your .NET type can be declared only;
- can make Rule Composer more business user friendly (if dare to apply this term to BRC :) ) abstracting database details away from vocabulary.
Of course, it takes away the ability to redefine rules “on the fly” or fix them should the database schema change. But you have a choice, and it's good to have one.