Something that wasn’t immediate obvious when I began developing BizTalk applications was where to store my environment variables such as database URLs and web service URLs for custom functoids, passwords for authentication with other systems etc.
SSO Storage. Having tried all the options below, my recommendation is to put them in the SSO storage by creating a custom library and custom functoid to make them easily accessible from maps and orchestrations. It may seem like hard work but it isn’t as bad as it looks and is definitely worht the effort.
First of all download the SSO snapin from Microsoft (seems odd this isn’t bundled with BizTalk) and set up your applications and variale key pairs. Note you will need to be in the BizTalk SSO Administrators AD group.
Then create a new library in your CommonArtifacts solution which will allow you to access SSO variables very easily. Use the SSOClient in the download from Microsoft as a guide for doing this. At the same time it is worth creating a custom fucnctoid which uses this new library so configuration viariables are also easily accessible from maps.
There is a great tutorial from Richard Seroter which explains how to do this in more detail.
BizTalk Configuration File. In my i initial applications I put environment variables in D:\Program Files\Microsoft BizTalk Server 2010\BTSNTSvc.exe.config (BTSNTSvc64.exe.config for 64bit installations) under the appsettings tag. I would access them by simply entering the following code into my orchestration and maps.
public string GetConfigString()
{
string connString=System.Configuration.ConfigurationSettings.AppSettings.Get("MyDatabaseConnectString").ToString();
return connString;
}
It became clear fairly quickly however that there were major drawbacks to this approach
- You had to restart the host instances for any changes to take effect
- Everything was unencrypted
- You had to change a separate dev.config file for the changes to work in the BizTalk test map tool in Visual Studio
A custom Database Table is another option for handling environment variables and may occasionally be suitable for storing setings. But of course the URL to theis database will need to be stored somewhere anyway and variables are not encrypted by default.
The Business Rules Engine should be used when complex rules which are likely to change are required to drive mappings and workflow. I’m still not a huge fan of the BRE but perhaps I am just not using it in the way it is intended just yet.