In the Sitecore Sunday Pt2: Programmatic Profile Association post I talked about Sitecore profiles that map 1 to 1 with existing site taxonomies and how to associate these profiles to your site visitors without having to re-tag all of your content.
As part of this process setting up profile, profile key, profile card and pattern card items is still required and this can be quite a time consuming task because for each profile key you have to:
- Create the profile key item
- Set its max value to 10 (or a scale of your choosing)
- Create a profile card item with the same name
- Set its radar graph to the maximum value for the profile key
- Repeat steps 3 & 4 for the pattern card
You can see with a lot of profile keys how this could become tedious.
Profile scaffolding to the rescue!
Download the Profile Scaffolder, which is a small and unobtrusive module (Helix stylee) that reduces the task outlined above to a single step:
- Create a profile key and give it a name. Done.
When you are running Sitecore with multiple load balanced content delivery servers, typically you would use Sitecore’s heartbeat page to monitor the health of each content delivery instance:
This service does more than just return a http 200 status letting you know that the site is running, it also iterates over each connection string defined in ConnectionStrings.config and executes a simple SQL query against sys.tables to check for un-responsive databases.
This is all fine and dandy until you throw Web Forms for Marketers into the mix. On a remote installation of Web Forms for Marketers a connection string is added to ConnectionStrings.config that communicates with a content management instance and looks something like this:
Unfortunately the heart beat page will try to process this connection string but it doesn’t know what to do with it so the page subsequently returns a 500 server error every time.
Fortunately Sitecore provides a way around this. If you look at the standard web.config you will not find a setting called:
But, the heart beat page is coded to check for it (expecting a pipe separated list) and by default excludes the connection string called “LocalSqlServer”.
As we know the best practice when adding custom settings to a Sitecore solution is to use include files. So, to fix this problem all we need to do is add (or update an existing) include file that contains the following:
<!-- stops the heartbeat page from returning an error 500 on delivery servers -->
<setting name="Sitecore.Services.Heartbeat.ExcludeConnection" value="LocalSqlServer|remoteWfmService"/>
And that’s it! We have a working heart beat page on a content delivery instance that also has Web Forms for Marketers installed.