You are tasked with building an automated site directory, most efficient, across site collections, and why not farm if you are there. (Piece of cake…so far). Add on top:
- Enable support for additional properties
- Try considering several lists too – with additional properties also
- Super-fast, super performing
- And I’m thinking – we should be able latter to use that as the source for our new global navigation menu
Not so easy anymore I hear you say – unless you jump right into programming your brains out. Or you could use Search – not bad as alternative, it does correspond to most of requirements, easily programmable and customizable, cross-site collections or even farms (if your environment is properly configured), but (yes, there is a “but”, otherwise this article would not need writing) – not a lot of information available other than Site/Web (aka sub-site) Title & Address and some content from the home page.
That is where one other great feature in SharePoint 2013 shines through, again pushing my favorite workload to day – Enterprise Search.
To recall in SharePoint 2007/2010 by making clever use of the STS_ContentClass one would be able to ask from the search index to return only Sites, or specific lists or library, or even list items. Let’s see examples (simply locate a Search center on your SharePoint installation and try these in search-box):
Remember the syntax is <Property Name><Property Operator><Property Value> more details on MSDN site @ http://msdn.microsoft.com/en-us/library/ff394509(v=office.14).aspx
So valid examples are:
- contentClass : STS_Web – returns only instances of SPWeb (aka Sub-sites, of course )
contentClass : STS_Site – returns only instances of SPSite (only links to the Top-level sites)
Figure 1 Searching for sub-sites
A lot others are available on the same lines (list not exhaustive by any means, but simply search the web for “content class” next to SharePoint, in your favorite browser):
|Searching for||Search Term (append to
|People||SPSPeople||returns only People (provided you have user profile syncronization running)|
|Sites and Sub-sites (aka Webs)||Return links to a top-level web or sub-sites|
|Site Collections||STS_Site||Only includes the actual Top-Level sites for any site collection. No sub-site information whatsoever.|
|Sub-Sites (aka Webs)||STS_Web||Only sub-sites (or webs) inside a site collection, not Top-Level sites|
|Lists or Libraries||
Return links to views (no information about items inside) with description taken from parent list/library
|Any list (generic)||STS_List|
|Document Library||STS_List_DocumentLibrary||Form Templates & Data Connections libraries, etc. are also included|
|Events||STS_List_Events||Returns links to all Views in all Calendars|
|Tasks||STS_List_Tasks||Returns links to all Views in all Tasks list|
|Items in Lists
Return the actual items (or document links) in a particular list/library matching criteria, but not the List/Library where item resides.
|Any list item (generic)||STS_ListItem||Pretty much every single item/document/page, etc.|
|Document Library Items||STS_ListItem_DocumentLibrary||Only actual links to Documents/Pages/Forms, etc.|
|Picture Library Items||STS_ListItem_PictureLibrary||Actual links to photos in a Picture library|
…and the list goes on.
Figure 2 All Site Collections where keyword “project” is present
This give you an idea but still the problem is only partially solved. As you might have noticed from the screenshots (in the 2nd also an additional keyword has been used – “project” – highlighted afterwards in bold wherever found), very few details are automatically crawled and available for search (I mean who care really that a sub-site or web has a size of x kilobytes? – I know none of my users do).
Content class has its uses in many other places, to create repeatable & fine-tuned experience I would recommend go for search-scopes in use it to narrow down results as soon beyond what end- user is supposed to type in the search-box (notice in the screenshots that 2 more tabs are available – one only search a pre-defined Managed-Path for Projects, whereas the other only show Documents, and nothing else).
See more on Waldek’s blog example http://www.mavention.nl/blog/creating-search-scopes-based-on-contentclass-properties, but lots others are available out there around the same topic (http://blogs.technet.com/b/josebda/archive/2007/03/23/site-directory-in-moss-2007-via-a-custom-search-scope.aspx).
Enough history, let’s get back to our original intent. I was saying that a great new feature is available with the SharePoint 2013 called “Indexed Property Bag”. This builds up on the already existing Property bag (available via 2 collections – AllProperties and Properties – each with its own issues – for more details head out to http://www.tekritisoftware.com/using-sharepoint-property-bag-in-your-sharepoint-application).
To sum up a list of properties are available by default with various objects in SharePoint (ever since 2007), such as Lists/Libraries, Sites & Sub-Sites, Web applications, etc. Most are set behind the scenes either by SharePoint (as you are performing various settings, such as changing the master page on a site) or by any custom code (or PowerShell scripts) that you are running on your SharePoint.
The new Indexed property bag comes with the added capability of being available for Indexing and Searching across. Practically this means that you could add as many information as you would to have visible as part of your search results and have those retrieved and finally exposed in the User interface. You are still limited to storing simple information (the only objects are actual Strings, other valid options being simple values such Integer, DateTime).
In PowerShell you would use something like this to store a new property (here to a SPWeb – a sub-site) – same could be achieved for any SPList and via C# code too.
$web = Get-SPWeb http://workspaces.b-i.ch/projects/prj01
$web.AllProperties[“Customer”] = “My Valued Customer”
How do we get to use it
- Make sure you populate all your custom properties at least for a single entity.
- Launch a full crawl (SP-CA > Your_Search_Service_App >Content Sources and select “Start a full crawl”)
- While still in SP-CA in the via the Administration page of the respective Search Service Application go to Search Schema (this has been changed from SharePoint 2010) and find the Crawled Properties. In order to be able to search across your custom properties, these must be indexed upfront and promoted to a Managed Property (just like with SharePoint 2010) and also marked as “Retrievable”.
- Once the operation is done for all your custom properties, run another full crawl.
- Try searching using a similar syntax as previously explained, but this time use your own property (name matching the one used to promote it as Managed property). This should return any results matching exactly your property based restriction. This also means that now you are ready to start tweaking your search results to include it in the display.
What has changed – quite a lot, as now by relying on Search capabilities, you can achieve everything and more, let’s summarize:
- Custom attributes added to our site collection or sub-site (think here – link to additional images for a slider, information about owners, purpose, category, contact, etc.) – not only retrievable, but also searchable directly, like with any other attribute-based search (e.g. “Give me all sites in a specific Category”)
- Should work not just for site & webs, but also other types of content – well the contentClass should deliver you pretty much everything
- Super-fast & super performing – search is known to be the fastest – the only potential issues being here – freshness of data. This could be quite easily solved by adopting the “continuous crawl” feature
- Can it be used later as potential “data-source” for a menu? Absolutely.
- It will throw in another one – The new Content Search Web Part and HTML based rendering templates allows for great user experiences, which could also be linked directly to the type of content you have within your search results. So practically, you could design specific user experience Links, different than results for Events or Tasks. I’ll tackle that in a future post with ample examples.
Meanwhile, enjoy SharePoint!