Dienstag, 24. Juli 2012

What’s new within SharePoint 2013 Search? – PART II

PART II: What happens with FAST in SharePoint 2013

(Concern that this is BETA stuff. Features and functions can be changed or shift until the final release!)


Fact 1: In SharPoint 2013 the two Search Engines “SharePoint Search” and “FAST Search Server for SharePoint” was combined in one Search Engine.
Fact 2: FAST as a standalone product is still available and supported. Details see here: http://support.microsoft.com/lifecycle/search/default.aspx?sort=PN&alpha=fast

Future of FAST ESP: See this statement from Rob Va from July 16: http://social.technet.microsoft.com/Forums/en-US/fastinternetesp/thread/86e5e64f-1fd0-4ee4-a025-1dea0f1693df

Mostly all the features / functions that we know from FAST Search Central Admin sites  had been integrated in Enterprise Search in SharePoint 2013:
Let’s have a look at the feature and functions level:
Managed Properties:
The technique with crawled properties and managed properties was similar in SharePoint Enterprise Search and FAST Search Server for SharePoint. But with FAST we had additional configuration options:
The functions / fields: Name, Type and Mappings to Crawled Properties were the same in both SharePoint 2010 Search Engines.
The features Sort Property, Query Property, Refiner Property and Full-text Index Mapping moved into the new Managed Property configuration:
There are some more options in the new SharePoint 2013 Managed Property configuration, but this will be part of “Part IV: Admin Stuff”.

Crawled Properties:
Crawled Properties are the same in FAST, Enterprise Search, and SharePoint 2013 Search.

Managed Property Extraction:
This section was completely reworked. In FAST 2010 we have to work with some PowerShell calls like: Get-FASTSearchResource dictionaries\spellcheck\sk_spell_iseck_en.txt and dictionary files based on an XML structure to include new terms. In SharePoint 2013 this feature used the Managed Metadata / Termstore to handle the term / dictionaries for company individual property extraction:

You can see that the function for ignore list and spell checking also moved to the Termstore. In detail we will have a look at this in Part III.

FAST Service Application:
So in fact only one integrated Search Engine left we didn’t have to configure the different Shared Service Applications for FAST Contend and Fast Query as we have to in SharePoint 2010:


Query Language / FAST Query Language:
FAST brings his own Query Language which was just different / extended from the SharePoint Search Query Language. Some of its characteristics are now found into Search Query Language. For example the XRANK Operator:
In SharePoint Server 2010, the XRANK operator was available only with FAST Query language (FQL). The XRANK operator provides dynamic control of ranking.

SharePoint 2013 Search does not longer support SQL syntax. Search in SharePoint 2013 supports FQL syntax and KQL syntax for custom search solutions.
For more details about building Search Querys ins SharePoint 2013 Search have a look here:

FAST Stuff:
FAST stuff and FAST specific components like the “extended WebCrawler” or commanding tools like indexerinfo.exe are no longer part of SharePoint, at least not part of the SharePoint 2013 Preview version.
Developing custom connectors / crawler is now standardized.

Content Processing:
In FAST for SharePoint 2010 we had the Advanced Content Processing Pipeline architecture:

In SharePoint 2013 this is part of the common Search Architecture.

Next parts in this series:
Part III: A look in the deep what’s behind the new Search functions like “Search Dictionaries”, “Query Builder”, “Query Client Type”
Part IV: Admin Stuff
Part V: Frontend Stuff

Freitag, 20. Juli 2012

What’s new within SharePoint 2013 Search? – PART I

PART I: Office 365 / SharePoint Online
(Concern that this is BETA stuff. Features and functions can be changed or shift until the final release!)
We now have access to the admin stuff of our Search Service Application. That’s a milestone forward! As we can see nearly all that stuff we missed in SharePoint Online v2010 is now available. We can configure our crawled and managed properties. Configure Result Sources which was Federated Result / Scopes in SharePoint Search 2010:
Here you see a confrontation between an Office 365 / SharePoint Online Search Admin site and an on-premise version:
So you see that we have still no access (maybe it’s coming up) to the “crawling” area. SO of cause that may be self-evident from Microsoft side. For me as a customer it would be nice if I can crawl my Extranet or data which will be bound in via BCS.
Integrating external Data in Office 365 / SharePoint Online Search can of cause be managed with the options coming with “Manage Result Sources”. As you can see we can connect “Remote SharePoint” which means an Index of an on-premise SharePoint 2013 installation or data coming from an Open Search source.

So with all this functions like “Manage Schemas”, “Search Dictionaries”, “Query Rules” and “Result Sources” we are able to build much more powerful Search Solution even Search Driven Applications also with Office 365 / SharePoint Online 2013.
Stay tuned for the next parts in this series:
Part II: What happens with FAST in SharePoint 2013
Part III: A look in the deep what’s behind the new Search functions like “Search Dictionaries”, “Query Builder”, “Query Client Type”
Part IV: Admin Stuff
Part V: Frontend Stuff

Donnerstag, 19. Juli 2012

Search Driven Applications with Office 365 / SharePoint Online - Part II


Part II: Deeper look what kind of properties and workarounds can be used within Office 365 / SharePoint Online to aggregate information based on the search engine.
As we see in Part I we have to use some tricks to build Search Driven Solution in Office 365 / SharePoint Online. Based on the content and the solutions in Part I we can build a Metadata & Taggs based Content-Browser. The idea behind is using a fixed query showing all the content in the index and then use the Tags & Metadata Refiner to filter and navigate.
The fixed query to show all the content is simply that one: %% or you use a fake query like that one:(IsDocument="True") OR (IsDocument="False") both show anything in the index.
Next Step is configuring the Refiner Panel to only show the Tags & Metadata. To do this we have to delete all the other refiner entries in the undelaying XML. (Webpart settings of the refiner webpart -> Refinement -> Filter Category Definition)

The result looks like this:

<FilterCategories>

<Category Title="Managed Metadata Columns" Description="Managed metadata of the documents" Type="Microsoft.Office.Server.Search.WebControls.TaxonomyFilterGenerator" MetadataThreshold="20" NumberOfFiltersToDisplay="20" MaxNumberOfFilters="20" ShowMoreLink="True" MappedProperty="ows_MetadataFacetInfo" MoreLinkText="show more" LessLinkText="show fewer" ShowCounts="Count"/>

<Category Title="Tags" Description="All managed metadata of the documents and social tags" Type="Microsoft.Office.Server.Search.WebControls.TaxonomyFilterGenerator" MetadataThreshold="20" NumberOfFiltersToDisplay="20" MaxNumberOfFilters="20" ShowMoreLink="True" MappedProperty="ows_MetadataFacetInfo,popularsocialtags" MoreLinkText="show more" LessLinkText="show fewer" ShowCounts="Count"/>

</FilterCategories>


You can see, that I raised the values for MetadataThreshold, NumberOfFiltersToDisplay MaxNumberOfFilters up to 20 and ad the ShowCounts element to the XML.

And here the result:

This is of cause not looking really nice. But it shows which data is available out of the box. For example: Based on the property ows_MetadataFacetInfo and popularsocialtags in combination with the property Count you can easy develop a TagCloud Webpart.

Necessary points here are: using this to excessive will falsify you search ranking etc. Another problem is the performance of this solution. By default only the first 50 items in the index are used to generate the entries in the Refiner (Webpart settings of the refiner webpart -> Refinement -> Accuracy Index). Setting this value up to high you get a poor performance during loading the side. Is the value to low the risk is higher that some Tags ore Managed Metadata values are missing. Before we come to a new point lets me says that this is not really a SearchDriven Solution because what we do is searching for all in the index and then filter it, but for the end-user this wouldn’t make an difference ;-)

The main focus is almost to build solution which are user-friendly and which do not raise up the doings for users. So let’s now have a look at useful properties which are created by the system itself.

As we see in the XML of the Refiner there are two interesting search property: ows_MetadataFacetInfo and popularsocialtags. We can combine those properties to build SearchDriven Applications based on a SearchQueryString as described here: LINK (on this site you also can find a C# code sample for using this stuff developing own WebParts)

For example I will have a SearchQueryString (for my environment of cause) showing me all content tagged with “Tag2” and the taxonomy filed “Region” is “Bern”

https://..../NB/Search/results.aspx?k=%25%25&r=%22owstaxIdRegion%22%3D%23511b3749%2D7ca3%2D4011%2D90d0%2Df88a8bc5fb50%3A%22Bern%22%20socialtagId%3D25dee478%2Df426%2D4dc1%2D9d25%2D340e9ecce093

Let’s disassemble this:

Query fragment
Clear text
meaning
k=%25%25
%%
Search for all in the index
r=%22owstaxIdRegion%22%
R=”owstaxIdRegion”
The managed property the system created from the taxonomy field
%20socialtagId

%blank%socialtagID
The given tag “Tag2”

(SharePoint creates for every Managed Metadata filed crawled properties and managed properties as described here: LINK)

You can use this SearchQueryString now in a SearchResult Webpart or as a fixed link to provide information coming from all crawled content in your Office 365 / SharePoint Online filtered on: “Tag2” is given and Region is “Bern”.

This technique also works similar in the new Office 365 / SharePoint 2013 preview version. The SearchQueryString syntax will be a litte bit diferent, but the idea behind is similar. Of cause with the new versions of Office 365 and SharePoint we have much more options and opportunities. This will be part of the next session. ;-)

In addition there are some very interesting 3th party tools for navigation and aggregating content based on Metadata which also work with Office 365 / SharePoint Online. For Example this one: http://www.metaengine.com/sptermcloud
For me the main handicap on this solution is that it only works with taxonomy fields. If you want to work with external data coming from BCS sources, Azure etc. you need to use the tagging feature because Managed Metadata isn’t available for external data.
Next part of the series we will have a look at SearchDriven Applications with the new Office 365 / SharePoint 2013 preview version…
Webcast with hands on system demos:

Mittwoch, 18. Juli 2012

SharePoint 2013 Search Result Webpart catches user context


One of the most missing things in the context of SearchDriven Applications with SharePoint 2010 was that the user context could not be catched without writing code / using JQuery or something. With SharePoint 2013 this is now no problem. The Result Webpart gives the option to configure filtering also for the user context:
Stay tuned - More details about Search, Search Driven Apps with SharePoint 2013 will follow soon...

Montag, 9. Juli 2012

Working with different Content Types in a SharePoint List containing Managed Metadata fields

I have a list which contains different Content Types. For each Content Type a “NewForm” is generates with SharePoint Designer.
This is because users should be able to create new entries for the different Content Types not only direct from the NewItem Ribbon Control. Users should create new entries via a Hyperlink.
The different Content Types contains Managed Metadata fields. For example the Content Type “Request”:
If you now try to create a new entry in the list based on a NewForm only the Managed Metadata fields contained in the Content Type which is set as “default” will work. If you have a Content Type within you NewForm which is not in the “default” ones you get the error message: Failed to get value of the "%FiledName%" column from the "Managed Metadata" field type control. See details in log. Exception message: Invalid field name.
But that’s not the only problem. Using for example the call: https://...../Support/Lists/Tickets/NewRequest.aspx  to create a new entry in the Tickets list based on the Content Type “Request” will generate an entry based on the Content Type which is set as default. In my case the system Content Type “Item”.
Both problems can easy be fixed by adding the Content Type ID to the URL call.
For example: https://...../Support/Lists/Tickets/NewRequest.aspx?ContentTypeId=0x0100025CC8C68E63EA4988F262B62EFD206804002A9070F736D1F94F982F921ABB30B4F1