Working with Managed Properties in Search-driven publishing scenarios
SharePoint 2013 does great job configuring things for you in search-driven publishing scenarios but there are a few things you should keep in mind to save yourself trouble.
Search-driven publishing
One of the great improvements delivered with SharePoint 2013 is search-driven publishing. The idea behind it is, that once content is crawled and included in the search index, it can be published in many different locations, such as portals or apps. In most scenarios the indexed content is structured data made up of different properties. This makes it possible to separate the content from its presentation. As a result you can not only publish the content on multiple channels but also do it consistently with the user experience used by each particular channel.
To some degree you could achieve similar result using the classic publishing available in the previous versions of SharePoint. The challenges there were however the limitations in scale, performance and content reuse. Often you ended up with hacking over-complex solutions which were a nightmare to maintain. With search-driven publishing in SharePoint 2013 all of this is the past.
Getting things done – for you
SharePoint 2013 helps you get things done in search-driven publishing scenarios. When setting up your information architecture all you need to do, is to specify your Site Columns and Content Types. As soon as you create some content using those Content Types and start a Full Crawl, SharePoint 2013 Search will automatically generate Crawled and Managed Properties for your custom Site Columns. With that you might think that there is nothing else that needs to be done to Search configuration and you can start publishing your content from the search index.
Crawled and Managed Properties behind the scenes
When indexing content using newly defined Site Columns, SharePoint automatically creates two Crawled Properties (their names starting with ows_q and ows_q_r) and a Managed Property linked to the ows_q_r Crawled Property. If you only want to display the data this configuration will work just fine. Often however you might need to use one or more Managed Properties to sort your data before publishing them or provide refiner options to your users and in those cases you will need to do some additional work.
The Managed Property automatically created by SharePoint when indexing contents of a new Site Column is of type text – this is always the case despite the type of the underlying Site Column. That Managed Property is associated with the ows_q_r Crawled Property which is also of type text. If you are sorting or refining your content based on text-based properties (such as name, status, location, etc.) this is fine, but if you have a date or a number Site Column this will return wrong results as the values stored in the automatically generated Managed Properties for those columns are treated as text rather than as a date or a number. The recommended way of solving this challenge is to map the ows_q Crawled Property, which contains the data from the Site Column in its original type, to one of the standard Managed Properties such as RefinableDateXX or RefinableIntXX.
One more thing about Managed Properties mapping
Although mapping Managed Properties to Crawled Properties isn’t complex at all, there is one more thing you should keep in mind. This is essential in cross-site publishing scenarios where your content is located in one Site Collection and published in another.
When mapping Managed Properties to Crawled Properties it is often a good practice to configure that mapping on the Site Collection- or maybe even Site-level. This allows you to isolate the configuration required for the proper working of one site from the configuration of other sites in your Farm.
Being a developer, thinking about separation of concerns, you might assume that the best way to configure the mappings is to do so on the site where the content is published. That way you retain flexibility of the published content catalog and leave the configuration of how the content is mapped to the sites subscribed to that catalog. Unfortunately, this assumption is wrong, and if you do this, all that you will see will be empty Managed Properties in your search results.
How SharePoint 2013 Search works, is that it crawls content which is then mapped to Managed Properties using the information from the Search Schema configuration and stored in the search index. Following this reasoning the mapping of Managed Properties should be done where the content catalog is stored rather than where its published. And although this might seem limiting, this is what is needed to have cross-site publishing work correctly.
Summary
When crawling contents of newly created Site Columns SharePoint 2013 Search automatically generates the corresponding Crawled and Managed Properties. The automatically generated Managed Properties are of type text and if you require the properties to be of their original type you need to do some Search Schema configuration yourself. Specific attention is required when working with cross-site publishing scenarios, where the Search Schema configuration should be done where the content catalog is located rather than where it’s being published.