Relating BDC entities for Search Indexing?

I think I might have come across a problem with using the BDC to index entity data in legacy systems. I’m sure I can’t be the first person to have hit this problem, but I can’t find a solution. Thus, I thought I’d blog it so other folks might be aware of it, and to open the problem up to suggestions.

I’m not sure I can describe the system I’m actually working on, so I’m going to use a slightly contrived example… Continue reading “Relating BDC entities for Search Indexing?”

Relating BDC entities for Search Indexing?

SharePoint can have Wildcard searching…

One of the most popular blog post on my site is, curiously, about the lack of wildcard searching in SharePoint out of the box. This, as it happens, is a bit of a simplification, and I’d like to be a bit clearer – even if it is more complicated.

  • Out of the box SharePoint does not have a way of searching for “App*” and getting all results such as “Apple”, “Application”, and so on. This is the wildcard search I was on about before.
  • You can do a wildcard search on a particular metadata property. “Title:App*” would return items with a title that contained “Apple”, “Application”, and so on. The down side is, you have to know the property you want to search on, and you have to know its name, which isn’t always easy or viable for users.
  • SharePoint Search service does actually support wildcard searching – just there is no way of using it with the out of the box controls. Essenially, it’s a problem of the user interface. The search service supports 3 different ways of querying it. This is why Corey Roth wrote his wildcard search webpart (on codeplex), and I’m sure there are others. He explains why he wrote it here, and what you give up by using Full Text SQL queries.

So, in short, if you’re able to do some custom development (or use Corey’s web part), and if you’re willing to trade off some other areas of functionality, you can get wildcard searching – but it’s not just out-of-the-box.

All of this is explained in ‘Inside the Index and Search Engines: Microsoft Office SharePoint Server’ by Tisseghem and Fastrup. I highly recommend it for developers working with Search.

SharePoint can have Wildcard searching…

Contextual Search Results Page Redirection via HTTPModule

So, I’m continuing my efforts at finding a way to handling Contextual Searching.

To describe the issue again, SharePoint allows you to search ‘This List’ or ‘This Site’. Unfortunately, these searches always show the ‘OSSSearchResults.aspx‘ results page, which is built into SharePoint, can’t be modified, and this means that you can’t use your normal ‘Search Center’ experience, which is usually modified and optimized for your users.

This is a shame, so I’ve been looking at ways of overcoming this problem. Continue reading “Contextual Search Results Page Redirection via HTTPModule”

Contextual Search Results Page Redirection via HTTPModule

Contextual Searching Via Search Box AppendQueryTerms

I’ve been looking at using the Search Box web part for a light-weight contextual search.

SharePoint allows you to search ‘This List’ or ‘This Site’. Unfortunately, these searches always show the ‘OSSSearchResults.aspx‘ results page, which is built into SharePoint, can’t be modified, and this means that you can’t use your normal ‘Search Center’ experience, which is usually modified and optimized for your users.

You can add a ‘context’ to a search with some of the search query terms. “Site:http://example/sites/docs” for example would restrict results to those below that URL. So, is there any way we can add that to our query? Continue reading “Contextual Searching Via Search Box AppendQueryTerms”

Contextual Searching Via Search Box AppendQueryTerms

Declaratively Point a Site Collection at a Search Center

Yesterday I wrote about the SmallSearchInputBox, how scopes only appear if you set a search center for the site collection, and how to set the Search Center in code.

Well, as is typically the way with CAML, I figured out how to do this declaratively later. Or, more specifically, I found that there is a feature I could call declaratively that would do what I want:

search-center-url-feature

<!-- SearchCenter Url feature -->
<Feature ID="7AC8CC56-D28E-41f5-AD04-D95109EB987A" >
<Properties xmlns="http://schemas.microsoft.com/sharepoint/">
<Property Key="SearchCenterUrl" Value="~SiteCollection/Search/" />
</Properties>
</Feature>

Yup, all I need to do is put that into my site definition…

Declaratively Point a Site Collection at a Search Center

Programmatically configure the Small Search Box to show scopes

Sharepoint’s ‘ordinary’ sites, such as Team Sites or Blank Sites, have a small search box (the SmallSearchInputBox) at the top which does not show search scopes, as we would be used to in a Collaboration Portal, for example…

search-blank-site-default

The reason for this is that they are not, by default, pointed at a particular Search Center – so they don’t have any idea what scopes to show. However, you can set this through the Site collection Search Settings…

search-site-collection-settings

And suddenly, your search scopes appear! Hurrah!

search-blank-site-now-with-scopespng

Now, what if we are creating a bunch of site collections? (Our current project could create quite a lot of site collections. And we need them created automatically, as required). Can we point them to a specific search center automatically? Continue reading “Programmatically configure the Small Search Box to show scopes”

Programmatically configure the Small Search Box to show scopes

Programmatically create pages – and Add Web Parts

I had an interesting problem recently with a Site Definition. I was trying to create a publishing page, which would not create as the correct content type. I still haven’t got to the bottom of why.

However, time was limited, and we were going to have to create a feature receiver to staple to our site definition anyway, so I had a look at creating a publishing page programmatically.

We needed a feature receiver as the customer wanted the home page of their site to have a ‘Search Box’ which would ‘Search this site’, but go to a custom results page in a Search Center. My plan was to use a Search Box Web part, configured to go to a custom results page, and to append the query term:

site: [url to site]

e.g. site:http://sharepoint/finance/

Naturally, you don’t know the URL of the site until the site has been created – so this web part would have to be created programmatically. Continue reading “Programmatically create pages – and Add Web Parts”

Programmatically create pages – and Add Web Parts

No federated searching of Google…

I’d a question from a customer:

I’ve installed the updates on our dev server and I’m playing around with the [federated] search, I don’t suppose you know if there is a Google connector for the search? Or is there coding involved to get the Google search results?

That seemed funny to me – Google not presenting results in XML? Well, apparently not. Google do not appear to provide an OpenSearch XML results service – at least, not for general search. Curiously, Blogs and News searches do.

There was a SOAP API that could’ve been used, but they are no longer issuing developer keys. Looks like they’re closing it down.

The best solution I can find – several suggestions of creating an intermediate web service to parse standard page requests. Which was the line I was thinking down anyway (I love regexes – which is a bit freaky. They’re like Sudoku, but fun!)

I do think it’s strange that Google don’t offer an XML service – I do get why; they make their money from advertising. But the competition offer it; my reply to my customer did end with ‘Or you could just use Live Search’.

No federated searching of Google…

Search a single Site

Previously, I’d posted about a customer who wanted to search a single list from a Search Box web part, but have their results shown in a Search Center results page. We ended up using a custom scope to do that.

This time, I’d a slightly different requirement. Another customer had a number of links, and these links would include search terms. They wanted to be able to restrict those searches to particular sites – and not just one particular site or set of sites, but to lots of different sites.

This made adding a scope an unappealing prospect. You’d have to add lots of scopes, and it’s not very dynamic.

One thing you can do in SharePoint search is search on the value of a particular managed property. A normal search would have query parameters like:

?k=King%20Lear

That would search all of SharePoint for ‘King Lear’. Well, we could also filter by properties – so we could do a search for:

King Lear site:http://intranet/somesite

This would encode to:

?k= King%20Lear%20site%3Ahttp%3A%2F%2Fintranet%2Fsomesite

and would restrict our search to a particular site (and subsites, actually – but close enough!)

This set me wondering, though – there is a URL managed property. Could I use this to restrict my search, rather than having an additional scope? Trying to restrict the search based on this didn’t seem to work very well. My results were… strange. I can’t figure out a logic, other than I was missing a lot of results. If anyone figures out what was going on, let me know.

So, the short is, I believe the above is a good way to restrict your results to a site. However, I can’t find an easy way of restricting results to a single list via a URL. I might have, if I’d spent longer looking!

Search a single Site

Search a single list, and don't use the OSSSearchResults.aspx page…

So, we’ve got a customer who’d hit the problem of the OSSSearchResults page that I’d mentioned before. To recap:

  • Global Searches in MOSS use a Search Center page for showing the results. These are nice, configurable, and can be made do quite a lot.
  • Contextual Searches (such as a particular list or site) use the standard WSS OSSSearchResults.aspx page. This isn’t nice and configurable, and changes will affect many sites.

Now, what would be great would be if we could have the contextual scope, but the global results page. Well, we can. Continue reading “Search a single list, and don't use the OSSSearchResults.aspx page…”

Search a single list, and don't use the OSSSearchResults.aspx page…