Potential problem with storing SSO Config

Topics: Bindings File, Settings Management and SSO
Jun 4, 2009 at 5:37 PM

First off, I'm no expert with SSO. My contact with it (besides installing it along with BizTalk) has been using it to store application configuration. So it's entirely possible I am misreading this situation.

In the past when I've setup application configuration in SSO I've used the 'manual' approach of building an SSO Config XML file and using BTSScnSSOApplicationConfig.exe to set/get individual application configuration name/value pairs. This was done using a process similar to that outlined here (http://felixmondelo.blogspot.com/2007_08_01_archive.html).

This time around I'm using the slicker facilities of the Deployment Framework to setup my applications config in SSO.

I ran the deployment script I'd created and noted in the output the successful creation of my SSO config store - hurray! When I used the SSOManage commandline tool with the -displayapp switch, sure enough I could see my application config store listed. It all looked good.

I wanted to be absolutely sure that the name/value pairs had been setup correctly, so I used the BTSScnSSOApplicationConfig.exe command-line utility to examine them...but no joy. I was assailed with the following Exception:

Exception: System.Runtime.InteropServices.COMException (0xC0002A05): The mapping does not exist. For Config Store applications, the config info has not been set at Microsoft.BizTalk.SSOClient.Interop.ISSOConfigStore.GetConfigInfo(String applicationName, String identifier, Int32 flags, IPropertyBag properties) at Microsoft.Samples.BizTalk.Common.SSOApplicationConfig.SSOSetConfigValues.Main(String[] args)

So then I turned to Richard Seroter's SSO Configuration Data Storage Tool (http://seroter.wordpress.com/2007/09/21/biztalk-sso-configuration-data-storage-tool/) - same problem, just this time in a dialog box.

So then I thought maybe it was me (Deployment Framework Newbie = High Cock-up Coefficient). I turned to the BizTalkSample that came with the Deployment Framework, deployed it and checked it using the Command Line Tools and Richard's Utility...the results were exactly the same.

I can't see why there appears to be a difference in what is stored in the SSO depending on which of the two installation methods are used?

Short of me having a shot development environment (everything else seems to be ok and nothing's shown up on the Best Practice Analyser or MessageBoxViewer) there appears to be something amiss here.

Any help gratefully received.

 

Coordinator
Jun 4, 2009 at 6:15 PM

Were you looking into it this way because you're not getting a value back at runtime that you specified in the settings spreadsheet?  We load into an affiliate application in the Config Store just one name/value that contains the entire XML exported from the settings spreadsheet (the one for the particular environment you are targeting).  The SSOSettingsReader component gives you access to your settings at runtime.

We do not explicitly support examining or otherwise manipulating the SSO data that we load through any of the tools that you mentioned.

Thanks,
Tom

Coordinator
Jun 4, 2009 at 6:33 PM
This approach allows for having one configuration story for deployment time (using spreadsheet with xmlpreprocess & binding files, etc.) and runtime (using the spreadsheet as a set of name-value pairs, per environment.)

On Thu, Jun 4, 2009 at 12:15 PM, tfabraham <notifications@codeplex.com> wrote:

From: tfabraham

Were you looking into it this way because you're not getting a value back at runtime that you specified in the settings spreadsheet?  We load into an affiliate application in the Config Store just one name/value that contains the entire XML exported from the settings spreadsheet (the one for the particular environment you are targeting).  The SSOSettingsReader component gives you access to your settings at runtime.

We do not explicitly support examining or otherwise manipulating the SSO data that we load through any of the tools that you mentioned.

Thanks,
Tom

Read the full discussion online.

To add a post to this discussion, reply to this email (biztalkdeployment@discussions.codeplex.com)

To start a new discussion for this project, email biztalkdeployment@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com




--
scott colestock
612.559.0580
Jun 5, 2009 at 9:57 AM

Thanks guys, that clarifies things - I said I was no SSO Expert!

Tom, I hadn't got as far as retrieving the config data within an Orchestration. As I was new to the Framework I was taking things step-wise and I wanted to verify that my config data really was in SSO before I tried to retrieve - that way if anything went wrong with the retrieval I'd know the problem was there and not in the SSO storage step.

I appreciate now that you are storing the config data in a different format to what these tools are expecting - hence the exception I was getting back.

From p.13 of the version 5.0 guide I can see references to how you could create and set the value for individual config name/value pairs using the Updatessoconfigitem task in a customSSO target (is this name significant). Also, I can see in the VS.NET add-in menu a menu item 'Update SSO' - which I am assuming re-applies the DEVL_settings.xml file to the SSO when you are working in the IDE.

My next question would then be, 'what process do you recommend for managing the values held in the SSO config store once the application is deployed on a server'?

I've not got as far as a server deploy yet so I'm unclear of what options exist there. I'm assuming you don't need to do a full undeploy/deploy cycle just to change these values in test/production, so could you point me in the right direction for how to achieve this with the Deployment Framework please?

Thanks for the prompt responses guys, much appreciated.


Coordinator
Jun 5, 2009 at 3:02 PM
There is a command line utility that allows you to either:
1) Update individual name/value pairs or
2) Reimport a particular environment's name/value pairs in total.

See SSOSettingsFileImport.exe - you can use a "/?" to get help.

2009/6/5 RedDwarf <notifications@codeplex.com>

From: RedDwarf

Thanks guys, that clarifies things - I said I was no SSO Expert!

Tom, I hadn't got as far as retrieving the config data within an Orchestration. As I was new to the Framework I was taking things step-wise and I wanted to verify that my config data really was in SSO before I tried to retrieve - that way if anything went wrong with the retrieval I'd know the problem was there and not in the SSO storage step.

I appreciate now that you are storing the config data in a different format to what these tools are expecting - hence the exception I was getting back.

From p.13 of the version 5.0 guide I can see references to how you could create and set the value for individual config name/value pairs using the Updatessoconfigitem task in a customSSO target (is this name significant). Also, I can see in the VS.NET add-in menu a menu item 'Update SSO' - which I am assuming re-applies the DEVL_settings.xml file to the SSO when you are working in the IDE.

My next question would then be, 'what process do you recommend for managing the values held in the SSO config store once the application is deployed on a server'?

I've not got as far as a server deploy yet so I'm unclear of what options exist there. I'm assuming you don't need to do a full undeploy/deploy cycle just to change these values in test/production, so could you point me in the right direction for how to achieve this with the Deployment Framework please?

Thanks for the prompt responses guys, much appreciated.


Read the full discussion online.

To add a post to this discussion, reply to this email (biztalkdeployment@discussions.codeplex.com)

To start a new discussion for this project, email biztalkdeployment@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com




--
scott colestock
612.559.0580
Jun 9, 2009 at 11:27 AM

Hi Scott,

That's brilliant, I knew it would be there somewhere - thanks for Fast-Tracking the new boy! ;-)

One suggestion I had regards the new documentation you are working on for the v5.0 release. I think it would be extremely helpful to have a summary section (maybe in an appendix or some such) that called-out:

 - Exactly what will be installed/de-installed by the MSI, how this varies between development box and server deploys and what properties etc. can be used to alter this behaviour.

 - Exactly what will be deployed/undeployed by the deployment project file, how this varies between development box and server deploys and what properties etc. can be used to alter this behaviour.

 - A section that outlines (bullet-points - activity diagrams/workflow diagrams would be great) the key processes you'll go through in the development cycle, server-deploy cycle and operational support and what parts of the Deployment Framework (and the relevant settings) would come into play.

I know you've a day-job and extensive documentation is a big-ask but I know that I, along with many of my fellow developers, would have found this sort of material a real boost in getting up to speed and leveraging all your's and Tom's investment.

Thanks for all your hard work.

Coordinator
Jun 9, 2009 at 5:35 PM

I completely agree that we need significant additions to the documentation, and your suggestions are great.  I think there is already a documentation-related issue on the Issue Tracker -- perhaps you can add your suggestions as a comment to that issue.  We rely very heavily on the sample at the moment with the documentation having decent coverage on some topics and very thin in many others.

My excuse is that with the summer season and subsequent yard work and various other time pressures, I am having trouble finding time to tackle all of these relatively minor but important fixes.  The toughest one is the documentation, which I expect to take 40+ hours.  I very much want to keep moving this forward and wrap up these items.  I don't know when I can get through it all, so I appreciate your (and others reading) patience in the meantime.

Thanks,
Tom

Feb 14, 2011 at 7:25 PM
Edited Feb 14, 2011 at 7:27 PM

We are evaluating the BTDF for addressing our deployment needs and are facing some challenges with SSO. We have been using Richard Seroter's tool on SSO (http://seroter.wordpress.com/2007/09/21/biztalk-sso-configuration-data-storage-tool/) and were planning on migrating them to SSO MMC (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=94E07DE1-1D33-4245-B430-9216979CD587&amp;displaylang=en). 
When we tried it with BTDF we were getting the same error that RedDwarf has mentioned and while digging into that realized that other two options are similar in nature in terms of how they store/retreive value in/from SSO. BTDF addresses this in a different way. So, we are debating if we should use the BTDF approach to automate the whole deployment process, or still rely on SSO MMC approach and  use BTDF in other places. Following are two differences we have found:

1. Richard Seroter's tool or SSO MMC relies on "ConfigProperties" string while saving/getting data out of SSO:

((ISSOConfigStore)ssoStore).GetConfigInfo(appName, "ConfigProperties", 4, (IPropertyBag)appMgmtBag);

BTDF relies on a GUID "{56D74464-67EA-464d-A9D4-3EBBA4090010}", I guess which is better. But if we want to use either one as is (without modifying the code), we have to stick with that option, whereas Richard Seroter's tool and SSO MMC are compatible. [ BTW, this the reason of getting error "The mapping does not exist. For Config Store applications, the config info has not been set..."]

2. Richard Seroter's tool or SSO MMC stores the key-value pairs as key/value pairs in SSO, whereas BTDF stores them as one key/value collection for the whole application. So, if we start using BTDF for managing SSO, we will not be able to use other tools for the same. Also, as BTDF uses Xml serializer/deserializer, it might become a costly operation. At the same time, BTDF gives the flexibility of caching whole application as one hashtable and thereby reducing the SSO database trip. [We have a custom wrapper on top of SSOHelper (that comes with SSO MMC) for doing similar chaching.]

Can you please share your thought/justification on these points, so that we can make the proper decision?

Coordinator
Feb 15, 2011 at 4:24 PM
Edited Feb 15, 2011 at 4:24 PM

Are you using this SSO config data for anything other than your BizTalk apps?  Is your main concern how to view, edit and generally manage the SSO settings?

The Deployment Framework includes two "GUI's" for managing your settings.  One is the Environment Settings Excel spreadsheet (see http://envsettingsmanager.codeplex.com for details), which lets you store and manage your custom settings and their values across all of your deployment environments in one central location.  Two is a Windows Forms app that lets you connect to SSO at runtime and view and edit the setting values.  If you're looking for a GUI to manage the settings, there is no advantage to the other tools -- just a different implementation.

We are not tied to a specific GUID when it comes down to naming and separating your settings.  When you deploy your settings to SSO with BTDF, you'll see a Config Store Affiliate app in SSO named the same as your ProjectName property value.  Each of your BizTalk apps configured with BTDF will deploy to a unique SSO app.  You're also free to deploy to a common SSO app and then access those common settings from any of your BizTalk apps.  We include a very simple .NET assembly that provides an API to the settings stored in SSO.

As for the XML serialization, I would not even give that a second thought.  You'd have to store a massive XML file for the load time to be even slightly perceptible -- and even then it is a one-time hit during app startup.

Again:

  • We provide a central, easy-to-use location for storing and managing all settings for all environments when they are not deployed (the Excel spreadsheet)
  • We provide a WinForms GUI for viewing and editing settings and their values when they are deployed (included with your BizTalk app deployment)
  • We provide a simple .NET API for accessing settings at runtime (using a user-specified Affiliate app name, not just the current BizTalk app's name)
  • Performance of our SSO infrastructure is fast enough that it's not even a factor in measuring runtime speed
  • We provide the additional flexibility of using the settings for binding/XML file transformation

I've been working with our infrastructure for years, and have never run into a scenario that we didn't handle.  Do I wish that our settings were directly compatible with the other tools?  Sure, that would be less confusing for everyone.  About all that would need to change for us is to write each of the settings to a separate SSO key/value pair instead of writing the XML as a block.  That's something that we can consider for a future release.  I believe that our model traces back to Jon Flanders, who also long ago created an SSO settings tool for BizTalk.

I hope that makes things more clear!

Thanks,
Tom

Feb 15, 2011 at 7:00 PM

Thanks Tom for the prompt and detail response...

We use SSO config data for storing BizTalk apps only (at least so far!). There is no doubt that BTDF addresses the BizTalk deployment need end-to-end, that no other available option does. But, with the multiple available options on SSO tools, we are mostly worried about interoperability with multiple available tools, specially when Microsoft has released SSO MMC and not sure about its future road-map on standardizing it. 

Again, my point regarding the GUID dependency was on interoperability with other tools. As long as we are tied with single tool, there is no problem. [This is not the SSO affiliate application name. I was referring to the second parameter of ISSOConfigStore::GetConfigInfo( ), which as per MSDN is 'String containing the identifier for the config info. This string is typically a GUID string.']

Regarding XML serialization/deserialization: Will it not be called after each cache refresh as part of ClearAllCachesIfRefreshIntervalExpired( ), which is defaulted to 60 sec, rather than app start only? Again, there are both sides of it... replace multiple individual database calls with a single (a bit more time taking?) database call.

Coordinator
Feb 15, 2011 at 8:02 PM

We could switch to use the same GUID as Microsoft's SSO MMC and write the name/values into individual SSO key/value entries.  That should cause all of our settings to show up in that tool.  Due to backwards compatibility of existing data out there today, it would most likely appear as an option in BTDF to enable or disable SSO MMC compatibility.

I have not given much thought to the SSO MMC tool because it just "appeared" out there on MS Downloads and I've never seen any comments from the BizTalk team as to where it came from, why it exists and if anything will be done with it in the future.  For that reason, I personally wouldn't worry about it.  Richard's tool is just something that he built for himself and shared.  I'm only concerned with BTDF being compatible with SSO tools released by Microsoft.

You're right on the cache refresh, but really, even if your configuration somehow got to be 1MB in size (which is vastly bigger than any I've ever created), XML deserialization takes milliseconds.  The XML serializer is dynamically compiled at first use, and that generated code is reused within the AppDomain.  I'd be amazed if you could measure the runtime impact of our SSO config initialization.

Thanks,
Tom