So I am currently architecting and developing a BizTalk 2006 SAP Integration solution for a customer.  This is really great stuff.  One of the key designs of this solution was using SSO to store SAP configuration data along with other custom data.  In my opinion if you are thinking about using configuration data inside of BizTalk you must take a serious look at SSO as a data store.  One of the gems out there to get someone up to speed very quickly is two samples from MS, get them here.  The ones you want to look at are the ‘Enterprise Library 2.0 with BizTalk Server’ and ‘SSO as Configuration Store’.  The former one includes the design and runtime assemblies that extend the configuration provider allowing you to use SSO as a configuration store while using Enterprise Library (or someone else’s product) which I feel solved the problem of why developers never used the SSO in the first place.  I’ve been to many customers that are currently using BizTalk and because maybe they didn’t understand the ins and outs of SSO, they ignored it completely.  On a little side note, if you want a good place to start learning about SSO go to Richard Seroter’s blog about SSO here.  He’s a great talent in the BizTalk space.  Now where was I? Oh yes so the second sample is a great introduction on actually using the tools provided out of the box to enable you to create an ‘Affiliate Application’.  What is an ‘Affiliate Application’ you ask?  Basically the AAs are logical containers that represent a system use what to use SSO with (SAP in my case).  Now AAs can be grouped into several types (of course) and those types are Individual, Group and Host Group. 

For this article I’ll be focusing on Individual types which offer a 1:1 mapping between a windows based account and non-windows account (e.g. SAP account).  Now since SAP uses basic authentication credentials (username and password) so the mapping is quite easy.

Now in order to enable SSO you can use the command line utility SSOManager.exe -enablesso as SSO is not enabled by default.  Now the easiest way to send data into SSO is by using an XML document and using the SSOManager.exe -createapps this will tranverse the XML document and create an AA and key-value pairs.  Here’s a sample XML file to send in: 

<?xml version=”1.0″?>
<sso>
 <application name=”AppMgmtUsingSSOApp”>
  <description>AppMgmtUsingSSOApp</description>
  <appUserAccount>BizTalk Application Users</appUserAccount>
  <appAdminAccount>BizTalk Server Administrators</appAdminAccount>
  <field ordinal=”0″ label=”reserved” masked=”no” />
  <field ordinal=”1″ label=”connectionString” masked=”yes” />
  <flags configStoreApp=”yes” allowLocalAccounts=”yes” enableApp=”yes” />
 </application>
</sso>

Notice the 0 ordinal being reserved, this must be set as so, or an exception is thrown.

Now MS always gives you at least ten different ways to do the same thing.  So another way to enter your data in the SSO data store you need the SSO Client Utility that comes with the Enterprise SSO bits.  If you look at the BizTalk help files and search for ’How to install the SSO Client Utility’ you’ll find the steps involved.  Developers can also programmatically read and write data to the SSO store using the SSOConfigStore object.  Here’s a sample for reading and writing configuration to the store:

public static string Read(string appName, string propName)
{

            try
            {

                SSOConfigStore ssoStore = new SSOConfigStore();
                ConfigurationPropertyBag appMgmtBag = new ConfigurationPropertyBag();

                ((ISSOConfigStore) ssoStore).GetConfigInfo(appName, idenifierGUID, SSOFlag.SSO_FLAG_RUNTIME, (IPropertyBag) appMgmtBag);

                object propertyValue = null;
                appMgmtBag.Read(propName, out propertyValue, 0);

                return (string)propertyValue;

            }
            catch (Exception e)
            {
                throw;
            }

}

public static void Write(string appName, string propName, string propValue)
{
            try
            {

                SSOConfigStore ssoStore = new SSOConfigStore();

                ConfigurationPropertyBag appMgmtBag = new ConfigurationPropertyBag();

                object tempProp = propValue; 
                appMgmtBag.Write(propName, ref tempProp);

                ((ISSOConfigStore)ssoStore).SetConfigInfo(appName, idenifierGUID, appMgmtBag);

            }
            catch (Exception e)
            {
                throw;
            }
}

Notice the use of the ConfigurationPropertyBag object which is just a class that inherits from IPropertyBag which signature looks like this:

public interface IPropertyBag
{
        void Read(string propName, out object ptrVar, int errorLog);

        void Write(string propName, ref object ptrVar);

}

Now in term of using this data store to hold SAP data mappings, first we need to find out what SAP needs in addition to just username and password to gain access to the system.  Here’s a list of keys that we need to set in our key-value pairs:

• SAPInlineHostName
• SAPInlineClientNumber
• SAPInlineSystemNumber
• SAPInlineUserName
• SAPInlinePassword

So once you setup these key-value pairs, you can configure your adapter by selected the AA from a dropdown of available AAs in the configuration window thus not having to fill out username and password on that screen.  To the adapter the AA is mutually exclusive to a UserName and Password pair.  Internally after looking at the adapter code, the adapters make a call to the SSO with a ValidateAndRedeemTicket method passing in the message itself and the AA information and getting the credentials in the form of a string[] object in return. 

I guess my point in this article is just to bring awareness to SSO because as I look out onto the BizTalk landscape I’m not seeing customers using it (1) to its full potential and (2) at all and I find SSO as a value add to most solutions.  So please get out there and download the samples and enjoy.  I’m sure to be posting more about SSO in the near future so stay turned.