Store config-info in BizTalk SSO

Introduction

I have started looking the Business Process Management (BPM) scenario and this time I will talk about its usage of BizTalk's Single Sign-On (SSO) to store configuration information. The SSO is normally seen as something that is not directly used by applications (at least I do), it's primary purpose to me is to be used by internal BizTalk components (e.g. adapter configuration) aside from the actual SSO scenarios. But there is actually nothing that stops you from using SSO is your BizTalk applications, which the BPM scenario proves.

But let's start with a search-poll to find out what others have written about this. When I search for "ISSOConfigStore GetConfigInfo" I get four hits! My conclusion is that these APIs are well hidden secrets, otherwise someone, somewhere would have written something about them.

SSO in BPM

In the BPM scenario the SSO is used to store this info: cable provisioning system location, total stage count and the cache refresh interval. The first two are actual business data while the cache refresh interval is used internally by the SSOConfigHelper to determine how often it should refresh the cached data.

The class used to access the SSO by the BPM scenario is SSOConfigHelper (located in the Utilities project). During initialization this class reads from the SSO and caches the values, the cache is then refreshed by creating a timer which will fire an event at regular intervals. The actual reading of SSO configuration values are pretty simple as a call to ISSOConfigStore.GetConfigInfo fills a property bag with all key-value pairs for the specific application.

Accessing SSO in your Application

At a high-level the code to read data from SSO looks like this:

ConfigurationPropertyBag configBag = new ConfigurationPropertyBag();
ISSOConfigStore ssoStore = new ISSOConfigStore();
ssoStore.GetConfigInfo("ApplicationName", guid, 4, (Microsoft.BizTalk.SSOClient.Interop.IPropertyBag)configBag);
object prop = null;
configBag.Read("YourPropertyName", out prop, 0);
string val = (string)prop;

When looking for info about ISSOConfigStore you get directed to the BizTalk 2004 documentation ISSOConfigStore.GetConfigInfo@MSDN. The docs say that the second parameter to GetConfigStore "Contains the identifier for the configuration info. This string is typically a GUID." The BPM scenario does not use a GUID, which only proves that any string can be used.

Jon Flanders has written a bit about using SSO to store configuration information and he also has some code to download, read more here.

Pros and cons

The biggest advantage of using SSO to store config info is that exactly the same values are available to all servers in the installation. There is no need to distribute a config-file across multiple servers when a value changes, you eliminate the risk of using different config info for different servers. Another advantage is that all information in the SSO is automatically encrypted which makes it harder for someone to read it. However, this is only a false sense of security if you don't limit access to your SSO application config store (and to tell the truth I don't know how to do this, hence that might be a topic for a future post...) as otherwise anyone who can write code can write an application which reads your "secured" config info.

The biggest disadvantage of using SSO to store config info is that it is dependent on BizTalk. In many organizations there are standards that describe how you typically do thing in a development project (this is often called a Programming Handbook), one of many topics in such a document is (or should be) how to handle configuration information. It may be hard to change a companies standard config store is that not all projects use BizTalk, and even those that do may have web servers etc. which may not be able to access the SSO database due to FW issues.

Another disadvantage is that the admin GUI to SSO is not very good, or more specifically it doesn't exist! There is a command line tool which can be used to access part of the SSO information, but it does not support application-level config info. If you wish to have a GUI/command line application to manage your information you will have to write it yourself!

Conclusion

Even though it is possible to use SSO to store configuration information it is not always the most appropriate way to do it.

I will probably continue to advocate using my configurationHelper class as it is available to web, thick client and any other services.