Let’s take it from the beginning. Using Best Bets, i.e. hard-wiring a certain result item to a particular search term, is a great way for Search Administrators to make sure end-users find what they’re looking for. Interestingly enough, there’s sometimes a slight contempt towards Best Bets in the technical community. Some people seem to think that the search solution’s relevance model should be able to stand on its own, and make sure the best results are always returned at the top of the results anyway.

But as a Search Administrator, if you could increase the perceived end-user experience a lot by a just a little manual (or semi-automatic) labor, wouldn’t you do it? Sure you would. One way of doing that is simply to look into the top X search queries in your query logs, and spend a few minutes on each search query and hard-wire a certain result item against it.

Anyway – we’re on the Technology section, so let’s get dirty.

In FS4SP, Best Bets are managed through the FAST Search Keywords page under Site Collection Administration. Adding a new one is easy: you start by creating a keyword, and then attach a Best Bet to it. Simple enough.

Let’s say you added the keyword “Comperio”, with the definition “Microsoft Search Partner of the Year 2011”. You then attached a Best Bet to it, linking to Comperio’s web site. With the minimal configuration, you’d end up with something like this:

Cool! You got yourself a Best Bet, and this is how they’re shown on the majority of FS4SP deployments out there. However, the Best Bet is not the only thing showing. The first star is showing the keyword itself, a long with its definition.

Let’s say you want to save some pixel real-estate, and decides that showing just the link is enough. At the Edit Keyword page, there’s no switch saying if to show the definition or not, but you can remove the text altogether from the text area shown below. That ought to do it!

Unfortunately, the result is not much better. We still get two stars, only now the keyword definition text is removed. The keyword itself is floating around by its own above the Best Bet – and not a single pixel was saved from vertical misery.

There’s no other setting on the FAST Search Keywords page to fix this – but there’s still a nice work-around. Enter PowerShell!

In an FS4SP shell, get hold of a Search Setting Group object corresponding to your Site Collection. If you only have one site collection, you can do:

$ssg = Get-FASTSearchSearchSettingGroup

If you have more than one, and haven’t named the group manually, pass in the id of your site collection to the the cmdlet’s –Name parameter. Running the two lines below in a SharePoint Management shell will print the id:

$site = Get-SPSite -Identity <a href="http://&lt;site collection root&gt;">http://&lt;site collection root&gt;</a>
$site.ID

When you’ve got hold of the search setting group, you can use it to view all internal information about the keyword:

PS C:\FASTSearch\bin> $ssg.Keywords.GetKeyword("comperio")
Synonyms        : {}
BestBets        : {Comperio}
FeaturedContent : {}
Promotions      : {}
Group           : Microsoft.SharePoint.Search.Extended.Administration.WCFClient.SearchSettingGroupImplWCF
Definition      : <DIV> </DIV>
Term            : comperio
LastChanged     : 1/27/2012 12:36:57 AM
Id              : 2

Looking at the Definition property, you’ll notice that’s it not actually empty at all – even though you’ve clearly removed all text from the definition text area. It contains the HTML entity for a non-breaking space wrapped in a <div> tag! Turns out that if you use the GUI to clear the definition, this is literally as empty you can make it. Even on a brand new keyword, without even specifying a definition. Bug or feature? I don’t know. But now knowing what the problem is, you can easily fix it for yourself by running:

PS C:\FASTSearch\bin> $keyword = $ssg.Keywords.GetKeyword("comperio")
PS C:\FASTSearch\bin> $keyword.Definition = $null

For the most part, Microsoft has done a great job integrating FAST into the SharePoint world, but there are certainly some areas where you notice there are actually two paradigms behind the scene: how things work in SharePoint, and how things (used to) work in FAST.

The primary key of the FS4SP index is one of those areas. In this post, I’ll try to make this a little more understandable.

First of all, the place where most people will notice that a primary key actually exists is in the crawl log on the FAST Content SSA.

Each indexed item is assigned an auto-incremented integer referred to as Item ID. All right, so let’s dig a little deeper.

If you’ve been reading up on FS4SP, you probably already know that there is an internal FAST-process called “qrserver”. It is responsible for receiving queries from the FAST Query SSA and internally forwarding the query to the actual index. You might also know that this process exposes a small web interface. For security reasons, it’s only available from within the server it runs on. More specifically: http://localhost:13280.

Searching for something here will return results in an internal XML format. The actual result items are listed under the <RESULTSET> tag a bit down in the XML. There are lots of things to talk about here, e.g. that the naming convention used internally in FAST is quite different to what is used when the results come back through the FAST Query SSA. A managed property for example, is referred to as a “field” internally. But let’s not fret over that now. Instead, let’s look at the first few properties of the first result:

After a few quick comparisons of the crawl log on the FAST Content SSA and the search results from the qrserver, it’s clear that the Item ID is stored in FS4SP’s index inside the property contentid. When comparing with the Item IDs listed on the FAST Content SSA, we also notice that SharePoint is prefixing the Item ID with “ssic://” when it’s stored in the index. In other words, the true primary key as used internally, is based on the pattern “ssic://[auto-incremented integer]”.

But as anyone who’s been using FAST pre-Microsoft can tell you, the contentid is actually not the primary key of the index. The real primary key is what’s stored inside the property internalid. The value of this property is the MD5 digest of the contentid, concatenated with the name of the content collection it is stored in. Let’s double-check, using our example. We had these two:

<FIELD NAME="internalid">8a832873c701c00135ce827d6c64c09c_sp</FIELD>
<FIELD NAME="contentid">ssic://33</FIELD>

Calculating the MD5 digest of the contentid correctly yields the internalid (sans the collection suffix):

md5(“ssic://33”) == “8a832873c701c00135ce827d6c64c09c”

Since the internalid is suffixed with the name of the collection, we can actually put several items with the same contentid into the index. The requirement being that they’re stored in separate collections, so that the concatenated internalid value becomes unique. In FS4SP however, we often use only the default “sp” collection. Luckily, SharePoint makes sure to assign the Item IDs so that they’re unique across all collections, hence creating unique internalid:s even though the items are in the same collection.

However, there are ways in FS4SP to index data without going through the FAST Content SSA, i.e. you can index data without letting SharePoint know about it. This happens when you’re using any of the FAST Search specific connectors or the command-line tool docpush. These tools talk directly with the index, bypassing SharePoint completely. Thus, the content id item won’t be assigned an Item ID using the “ssic://” pattern.

So, what happens instead? Let’s try it out. Using the docpush tool, we can send an arbitrary web page into the index:

Using the qrserver web interface, we inspect what was indexed:

In this case, the contentid property is the URL of the web page we specified. This makes sense as the URL is unique for the whole web, and as such it is also a good candidate for being a primary key in the index. A URL is just a special case of a URI, which is what many of the FS4SP command-line tools use when referring to the primary key of the index. Examples being the docpush tool (when deleting a item from the index with the –d switch) and the waadmin tool (used for retrieving link cardinality data for an indexed item).

To sum up with some key points:

• The primary key of the index is stored in a property called contentid, though in the SharePoint GUIs it is referred to as an Item ID and look slightly different. They relate to one another as: [contentid] = ssic://[item id]
• Items that are indexed using the connectors of the FAST Content SSA are assigned a contentid on the form “ssic://”…
• Items that are indexed with the FAST Search specific connectors or the docpush tool do not follow the same pattern, but are typically a proper URL or a value from a database.
• If a command-line tool calls for a “URI” to an indexed item, use whatever is stored in the item’s contentid property.