SharePoint 2013 Custom Search - Part 3 - Display Templates

This is the final part in a three-parter on leveraging SharePoint 2013 custom search and a business solution, this follows directly on from SharePoint 2013 Custom Search - Part 2 - Result Sources and Query and will focus on the display of results.

SharePoint 2013 makes heavy use of display templates throughout the platform. Microsoft have now made it easier than using XSLT (which is a relief!) to display search results and in a similar way to the way the masterpages are controlled, you simply upload a html/javascript version of your display template and SharePoint - via the use of jiggery-pokery and magic - creates the necessary .js file! Awesome!

Ok, so lets get to it! We saw before we 

SharePoint 2013 Custom Search - Part 2 - Result Sources and Query

This post follows directly on from my other post SharePoint 2013 Custom Search - Part 1 - Managed Properties which guides you through making your searched (crawled) data available to use in your solutions.
This post builds on this and uses this data in a meaningful way, pulling this into Search results by way of display templates - a new feature for displaying content in SharePoint 2013..

My end goal is to produce a search driven page that returns refine-able information about the way an IT project went, this information is captured in a retrospective meeting after the project has completed, the information captured is based around the 'feeling' e.g. positive, negative or warning.

The user experience i'm after is for a user to be able to search for a key word (or an asterisk * to search all content) and the same page display results showing custom information, with the ability to hover over these to provide further information.

The data for this is coming from a list, with columns that have been created, mapped and crawled following the principles outlined in my first post in this three-parter.

A list including crawled data, the next new thing to 2013 Search is the concept of a 'Result Source' this replaces the old 'scopes' from 2010. Head to Settings-Site Settings-Result Sources

You will see a list of Result Sources provided by SharePoint, take a look at these to familiarise yourself with the way they are created and the various ways these can be implemented.

To create a new result source, click (yes you guessed it) 'New Result Source'.
The purpose of this result source is to return results that only exist in a specific location - in this case the list above. So the settings we want here are:
Name: RestrospectiveLearning
Protocol: Local SharePoint
Type: SharePoint Search Results

Now for the query, hit 'Launch Query Builder'. Here we're stringing together three query parameters to get the right results.

?{searchTerms} - Is the internal variable for whats typed in the search box
Path:http://xxxx - Is the URL path of the results we're after
(contentclass:STS_ListItem) - Is the type of data we're looking to retrieve

Testing your query will return no results as there is no search term, so this is correct.

The next thing to do is create a page on which to add a search box and search results webpart, this will be the home for our users for this particular solution, they shouldn't need to navigate away from this page.

Here we have a plain old web part page and as you can see I've added a Search Box web part, Search Results web part and a Refinement web part (ok I've missed one, you can see a Script Editor web part here, I tell you what this does later, I promise!)

We need to link the Search Box and the Search Results web parts together so the results go to the right place! Simply edit the Search Box properties and tick the box that send results to the Search Results web part.

Now to configure the Search Results web part, so again edit the web part and choose 'Change query'

Next we see the query builder that SharePoint 2013 uses all over the place, this is similar to the one we used creating the result source.

This time we simply select the result source we created earlier. 

As for the refinement panel, edit the webpart and provided you have set the managed property (part 1 of this series) to 'Refinable' it will be available to select here, add the ones you wish to refine your results to 'Selected refiners'

Now for the elusive Reset Button you saw earlier. The reason this is included is I want results to appear for the users when they load the page. To achieve this, I need a wildcard (*) as a search term. I've added a script editor webpart and included the following javascript, firstly this changes the URL on page load to include the query '*' and secondly do the same thing when a button is pressed (labelled 'Reset').

<script type="text/javascript">

window.location =  '/sites/Retrospective-Learnings.aspx#k=*'

</script>

<div>

<input type="button" name="ResetBttn" title="Click to reset" style="margin-left: 0px;" onclick="location.href = '/sites/Retrospective-Learnings.aspx#k=*'" value="Reset">

</div>

Now to test.

Typing a term in the search box will now display desired results from the correct list in the search results web part. However, these are not styled as we would like as you can see..

Checkout SharePoint 2013 Custom Search - Part 3 - Display Templates for how to style this and bring it all together.

SharePoint 2013 Custom Search - Part 1 - Managed Properties

This is the first in a three part blog which will focus on leveraging SharePoint 2013 Custom Search in a real world business solution, part one is creating managed properties, part two looks at getting these as part of result sources and querying, and finally part three brings it together with a bit of custom styling using display templates.

OK, so Microsoft have changed the way they have implemented Search in SharePoint 2013 - in quite a massive way if you didn't already know. 

Alongside some of the larger changes, there are a few smaller ones which aren't immediately obvious.
Once upon a time to configure managed properties, one had to venture into the 'Metadata Properties' section in 2010:

The game has changed a little, and this option is now embedded in 'Search Schema' in the 2013 world:

If you've already added managed properties in 2010 I hate to tell you how to suck eggs, but I'll cover it anyway as there are a few more changes, I'll point these out as we go on...

A few ground rules on managed properties and crawling -

Rule 1: You have to map a managed property to a crawled property

Rule 2: A crawled property is not a crawled property until its been crawled (kind of makes sense, but the next rule will clarify)

Rule 3: A crawled property is not registered as crawled unless there is some data against it

Rule 4: You have to run a full crawl before data in a crawl property is crawled

Hopefully that all makes sense, but basically, to add a managed property; create the column in SharePoint, add an item with data against that column, run a full crawl and the crawled property will be visible in central admin.

There will be a few of you reading this know your stuff that will be like 'hang on a minute, why do I need to map a crawled property to managed one in SharePoint 2013?'

Well the answer is - you dont! SharePoint 2013 has added a neat feature which creates a managed property automatically on a full crawl for any columns that contain data. However, I prefer to create mine manually for a few reasons.

Take the following two managed properties:

They both actually crawl the same value and will return the same thing, however the automatically created one (at the top of the screenshot above) you will see has a somewhat messy name appended with OWSTEXT. In addition, if you wanted this property to be searchable (which is extremely likely) you would have to edit the property as its created with only query and retrieve attributes.

So to create a managed property (after the rules above have been followed) choose 'Add New Managed Property' in the resulting screen give it a meaningful name (I would create this without spaces to make this easier to reference in javascript / html / xsl later):

Select the attributes that you wish this property to have:

Map this to a crawled property (you can map this to more than one crawled property!):

You are now able reference the values from crawled properties in your solutions using the managed property name. To read about how to achieve this as part of a business solution take a look at the second part in this series:

SharePoint 2013 Custom Search - Part 2 - Result Sources and Query

Using the power of SharePoint 2013 Search in your 2010 environment

So consider the scenario, you have a SharePoint 2010 environment running your corporate intranet, mySites, team sites etc. You want to make the move to 2013. Migration from team sites is going to take some planning and also some time, heartache, sweat and tears. As for the intranet that is simply going to be an absolute pain to move. 
So although migration is on the cards, you want to make the most of the some of the new features 2013 provides. For example the new search, continuous crawl, deep refinement and greater relevancy. Basically the kind of stuff people want from a search engine. Well you can, and on top of that you can do this so your users don't notice a change, except of course for better results!
What we can do is create a trust between your 2010 and 2013 farms, publish your 2013 Search Service Application and consume it in 2010 using the original 2010 Search Center, and here's how...

Within your 2013 Farm Search Administration, first check the default access account.

Back in 2010, this account needs adding into the User Policy to the web application(s) to be crawled with the ‘Full Read’ permission. (It’s worth pointing out here, both farms are on the same domain. Otherwise domain trust needs to be setup and you have to set searchadforests people picker property etc etc, this is a different blog for a different day)

Now add a new Content Source in 2013, here I have called mine ‘SharePoint 2010 Sites’ (you could of course add these URL’s to the existing Local SharePoint Sites content source, but you may want to scope these out later so I recommend separating them.

You can add schedules for full and incremental crawls or enable continuous crawling at this stage, but again you can come back to this later. When your happy with the settings, kick off a full crawl. 

Check in crawl log that you’re getting successes on the newly added content source.

Also check some results are coming back from the new content source when running a search in an SP2013 Search Center.

OK, time to add some trust between the farms. First up we need to dip into Powershell to get some certificates. Now, the way this works is certificates need transferring from the publishing farm to the consuming farm and vice versa, creating a two way trust. There are two certificates in question, the Root Certificate and the Security Token Service (STS) Certificate.
Just to make things a little complicated, both farms need each other’s Root Certificate, however only the publishing farm needs the STS Certificate of the consuming farm. SharePoint does try to explain this in the ‘Manage Trust’ dialogue located in Central Admin – Security.

On an SP2010 server, fire up a SharePoint Powershell window and run the following to grab the Root Certificate (the folder these are copied to needs to be created otherwise the command will error).

$rootCertificate = (Get-SPCertificateAuthority).RootCertificate

$rootCertificate.Export("Cert") | Set-Content C:\Cert\SP2010Root.cer -Encoding byte

And now for the STS Certificate

$stsCertificate = (Get-SPSecurityTokenServiceConfig).LocalLoginProvider.SigningCertificate

$stsCertificate.Export("Cert") | Set-Content C:\Cert\SP2010STS.cer -Encoding byte

Copy these off to somewhere safe on your local machine, or the machine you’re launching your Central Admin sessions from.

Before closing the Powershell window on the 2010 box, we may as well grab the farm GUID while we’re here, all will become clearer later on! Run the following and copy the resulting GUID it provides.

$farmID= Get-SPFarm

$farmID.ID

Head over to an SP2013 box, again fire up Powershell and run the script to get the root certificate, again copy this to your machine. Notice I’ve named these appropriately so we choose the right ones later!

$rootCertificate = (Get-SPCertificateAuthority).RootCertificate

$rootCertificate.Export("Cert") | Set-Content C:\Cert\SP2013Root.cer -Encoding byte

Right, now to apply these certificates in the respective farm’s Central Administration. Let’s get 2010 out the way first. Head to Security – General Security - Manage Trust, we’re going to add a new trust relationship, so yep, you guessed it, hit the new button. We want to give this trust a name, this is only really for you as an admin so pick something meaningful, I’m going for ‘SP2013 Farm Trust’.
Next, in the Root Certificate for the trust relationship section, click browse and locate the 2013 Root Certificate you copied earlier. Finally, leave the STS Certificate section blank.

Hit OK, and we’re done. Now for SP2013 CA. Again, same as before Security – Manage Trust – New.
This time I’m going for SP2010 Farm Trust as the name and applying the root certificate we extracted from the 2010 farm. This time though, we need to tick the box ‘Provide Trust Relationship’, provide if you want a Token Issuer Description, and add the 2010 STS Certificate in the final section of the Establish Trust Relationship dialog.

Hit OK, and that’s trust configured. Now we need some permissions. Still in SP2013 Central Admin head to Application Management – Manage Service Applications.
Find the ‘Application Discovery and Load Balancer Service Application’ highlight it, and choose ‘Permissions’ from the ribbon

Remember the GUID of the SP2010 farm we collected earlier? Now’s the time to make use of it.
Paste it into the picker in the Connection Permissions dialog.

And choose ‘Add’, this should resolve and give a bit more detail in the name, tick the full control checkbox and hit OK.

Repeat this for your Search Service Application also.

When done, leave the Search Service Application highlighted and we’re now going to publish this, so in the ribbon you’ll see a Publish button.

Hit this. In the resulting dialog choose your connection type (my farms are both internal and so not SSL secured I’ll be going for http), tick the ‘Publish this Service Application to other farms checkbox’, we’ve already added trust so no need to click the ‘add a trust relationship’ link. You will see a published URL, get a copy of this from urn through to svc. In the description text, put something useful in here.

Now let’s see the fruits of our labour and connect to the published Search Service Application from our 2010 farm! Head to 2010 CA, Application Management – Manage Service Applications. Choose ‘Connect’ form the ribbon and select the ‘Search Service Proxy’ option.

Paste in the published URL copied from the SP2013 publish operation.

Choose Ok and this will tick over for a moment or two and then hopefully tell you that there is a Search Service Application at the address you specified. Click on it to highlight it and the OK button will become active.
Just a quick note on the Add this service application’s proxy to the farms default proxy list. I’m not going to go into the whys and wherefores of Service Application proxy’s, but in some instances it may not be best to add this to the default at this stage. For example, in my circumstances, I have an up and running 2010 Search Service Application service our users, I plan to do a scheduled switch over to the 2013 search engine at some stage, but not right now. For this reason, I will be deselecting this box and at a later date editing the default proxy to remove the existing search and add this one. So just something to consider..

Anyway, after hitting OK, you get the chance to give this connection a name, again choose something meaningful.

Following this, and all being well, you should get a lovely successful message!

Finally we need to associate this with your web application(s) that you are running your searches from. There are a few scenarios here depending on your setup.

I mentioned before I didn't add my connection to the default proxy group as I have an existing SSA. If this is your case, then you can create a new proxy group in SP2010 (or use custom) and associate your new 2013 Search Connection leaving off your old one, and then in turn associate the desired web application(s) with the new proxy to use the new search.

In the case you added this to the default proxy group, one of the following will apply:
- You do not have an existing SP2010 Search, in which case you’re good to go.
- You have an existing 2010 Search. This will still be the default search provider. To make your web applications switch to the new 2013 one, head to 2010 Central Admin – Service Applications – Configure service application associations, click on the ‘default’ Application Proxy Group and you will see both your Search Service Applications ticked, notice the original one has the word [default] next to it, to set the other one active, click the [set as default] link

You could of course un-tick one of the Search providers here as well, which would do the same thing.

The settings made in the Configure Service Application Associations dialog are applied immediately and you can make searches from the respective providers and see the results!

There you have it, SharePoint 2010 powered by the much superior SharePoint 2013 Search engine.