Using custom fields in search results

Find out the given internal name of the custom field....

SharePoint search crawler identifies automatically all fields in a given contend source. This will work for all contend types the SharePoint search server can handle per default or an Ifiler is installed. Of cause SharePoint user defined fields in lists or document libraries are crawled.

There is an MSDN article that describes how to use custom fields in core search result webpart: LINK. It’s just an easy doing, you have to put you custom field to the field list in the Display Properties node of the search results webparts and modify the XSLT transformation (XSLT) to display the custom property. Details see the link above.

But there a two little catches: first is that you have to map the crawled property that includes your customer field to a managed property to use it in search results. But that’s not a real big thing. You can do this using PowerShell or via SharePoint central admin. For example see my post: Bring up crawled contend to the user or this MSDN article: LINK. But to do this you have to find out which crawled property represents you custom field. For this you have to find out the static name of the field. Of cause there are several ways to reach this goal. I used SharePoint Manager; a free tool you can download from codeplex: LINK.

Open SharePoint Manager on you SharePoint Server, navigate to the list containing your custom field and click the field. In the right section you see the details of the selected field. In the cell static name you will find the value needed:

(this is SharePoint Manager on a SharePoint 2007 Server. It works similar in a SP 2010 environment)

In my demo case the field name is “2011 Fällig” and the static name is “_x0032_011_x002c__x0020_F_x00e4_”

Another way to find out the static name is to analyze the URL. To do this go to list settings -> click on the column name in which you are interested -> on the change column page the URL will ends with the static name:

… 176%7D&Field=%5Fx0032%5F011%5Fx002c%5F%5Fx0020%5FF%5Fx00e4%5F

This will work fine for simple field names, but you see that it can be horrible in case of complex field names.

So know we can use the static name to find out the crawled property. For example via PowerShell. If you use PowerShell it’s important to know, that the system puts an “ows_” to the static name of the field to name the crawled property. So our crawled property looks like “ows__x0032_011_x002c__x0020_F_x00e4_”. The PowerShell call in my demo case is:

Get-SPEnterpriseSearchMetadataCrawledProperty -searchapplication b835108f-5a59-4348-9cfb-c71adc1415b0 -category SharePoint -Name  ows__x0032_011_x002c__x0020_F_x00e4_

Another and of cause in this case easer way is using the search function for crawled properties in the search service administration section:

Now that we have the name of the crawled property containing the contend of the custom list field we can map it to a managed property and use it in SharePoint search for filtering, display it in search core results ore what else…

I´ve reached the next Microsoft certification level….: Microsoft Certified Trainer… jep :-)

A little bit more social FAST search

This article refers a blog post from Christan Glesser: LINK . In his article Christian describes that FAST search isn’t able to handle social tags as the std. search can do. The point is that social tags are not provides as refiners in FAST search.

There is an crawled property in FAST search called:

urn:schemas-microsoft-com:sharepoint:portal:profile:socialdata:socialtagtexturl

This property contains links to mySites from users who used social tags.

The property is unmapped per default. If you map this crawled property to a managed property (here you can find how to do this: LINK) you can do a search like: %managedProperty%:searchTerm

For example:

There is a social tag name “tag1”. If you search with SharePoint std. search for some contend witch is tagged with “tag1” the result looks like this:

If you do the search with FAST the result is the same, but there is no tag refiner shown (as Christian described in his post). What we can do now, if we have mapped the crawled property to a managed property and of cause do a recrawl, is using this syntax as search query:

socialTag:tag1
(“socialTag” is the name of the managed property I created for mapping the crawled property to it.)

The result brings the mySite from the user who used the tag “tag1”. On his mySite we find the tagged document:

Not really nice, and of cause horrible to handle for end-users. I think this is just only a theoretic solution, but interesting anyway. Maybe this can be used in a search driven portal or something else….

Bring up crawled contend to the user (map indexed contend to a managed property)

In one of my last post I wrote about extracting data via xpath out of the “hithighlightedsummary” field (LINK) - here I want to show another method to make contend that is in the search index usable for user experience.

I just want to use the same SQL Table as in my previous posts. Also I want to bring up the field “ApkBezeichnung1” (which is called “Task” in the BCS SharePoint List based on this SQL table in the previous post) to the front

 So the underlying and crawled data locks like this:

Now let’s use some PowerShell calls to see what the search server, in my case the FAST search server knows about this contend source. The crawled contend / crawled properties are normally sorted in so called Metadata Categories. This PowerShell call shows all existing Metadata Categories on your server:

Get-FASTSearchMetadataCategory

As result we get something like that:

We see that there is a category called “Business Data” witch contains all crawled Data coming from any BCS source

Next we want to do is showing all crawled properties in the Metadata Category “Business Data”

Therefore we use this call:

Get-FASTSearchMetadataCrawledproperty |ForEach-Object{ if ($_.CategoryName -eq "Business Data") {$_.Name} }

Another way to find out details of the crawled contend / crawled property we want to bring to the front is this call:

Get-FASTSearchMetadataCrawledProperty -filter apkbezeichnung1

“apkbezeichnung1” is name of the field in the SQL table.

The –filter parameter does not support wildcards. Matching is case-insensitive, and matches a string anywhere within the name attribute of the crawled property:

So we now know that the field is crawled and that the name of the crawled property is “read listelement.apkbezeichnung1”.

To use the property in SharePoint Search we have to map the property to an existing managed property or create a new managed property. I will create a new one with these calls:

1.       $v1 = New-FASTSearchMetadataManagedProperty –Name "BCSTask” –type 1

2.       Set-FASTSearchMetadataManagedProperty –Name “BCSTask” –Queryable $true –

StemmingEnabled $false –RefinementEnabled  $false

3.       $v2 = Get-FASTSearchMetadataCrawledProperty -filter apkbezeichnung1

4.       New-FASTSearchMetadataCrawledPropertyMapping –Managedproperty $v1 –crawledproperty $v2

The result is:

We now have a managed property. It can be used in SharePoint Search after the next crawl of the contend source. The managed property contains contend from the database column “ApkBezeichnung1”.

Examples:

Now we can do something like this and use the new managed property “BCSTask” direct in the search box: search term: “BCSTask:Dongel”

Append an external (crawled) property from a BCS source to a search refiner

Append an external (crawled) property from a BCS source to a search refiner

In this case I will use a field from an SQL table as a refiner in my SharePoint Search. The SQL table contains information about ORDERS from external ERP system. This ORDERS list is accessible via a BCS connect from SharePoint and also you can search for those ORDERS via SharePoint search. There is a default refiner called AUTHOR in SharePoint search. So “author” is here similar to the creator of the ORDER.

Here is the SQL table. You can see the “VorAngelegtVon” field which contains the person who created the ORDER in the ERP System:

This SQL table is integrated in SharePoint via BCS. (How to do this is not part of this post). The result looks like this:

If you start a search with the searchterm “ERP_Orders” (ERP_Orders is the profile site name for this BCS source) you get a result set shown below:

This resultset contains entries from the BCS list “ERP_Orders” and you see only two refiners are available -> Sites which contains the source and the Modified Date

Next step is to find out if there is a crawled property containing the field “VorAngelegtVon” from SQL table / BCS Source. To do this I used PowerShell.

From PowerShell execute this command:

(There is no fundamental different using FAST Search or SharePoint Search in this case. You only have to check out using the correct cmdled )

Get-FASTSearchMetadataCrawledProperty -filter <name of the field>

(You see that I used the FAST search version. For SharePoint Search the cmdlet is SPEnterpriseSearchMetadataCrawledProperty)

In our case the command is: Get-FASTSearchMetadataCrawledProperty -filter VorAngelegtVon

The result shows that there is a Crawled Property containing the data we want to use. The name is “read listelement.vorangelegtvon” and it from the category “Business Data”, so we are on the right path.

Now let’s see the details for the property “Author”. This is an existing managed property, so we have to use another cmdlet:

get-FASTSearchMetadataManagedProperty -name <name of the managed property>

(For SharePoint Search the cmdlet is SPEnterpriseSearchMetadataManagedProperty)

In our case the command is: get-FASTSearchMetadataManagedProperty -name Author

You see that the property “MappingDisallowed” is set to False. That mean we can map our crawled property to this managed property. The property “Author” is also flagged as “RefinementEnabled”. This is necessary to be shown in the refiner panel.

To map the crawled property “VorAngelegtVon” to the managed property “Author” use the following command:

$vm = Get-FASTSearchMetadataManagedProperty -Name Author

$vc = Get-FASTSearchMetadataCrawledProperty -filter VorAngelegtVon

New-FASTSearchMetadataCrawledPropertyMapping -Managedproperty $vm crawledproperty $vc

(For SharePoint Search the cmdlet is SPEnterpriseSearchMetadataMapping)

To check if the mapping is created run this command:

Get-FASTSearchMetadataCrawledPropertyMapping -name Author   

Before the mapping is taking any effect a crawl of the contendsource containing the BCS source is necessary. An incremental crawl is enough.

After the crawl is finished you can work with the new refiner and filter the ORDERS by Author:

This can be the stage for a search driven solution showing the ORDER from the ERP system refined by the Creator / Author….

IMPORTEND: this works only for managed property who default set as a refiner. (Flagg “RefinementEnabled” of the managed property must be set to “true”).  If the managed property is not set as a refiner by SharePoint default you must edit the XSLT for the Refinement Panel -> How to do this you can find for example here:  SharePoint analyst hq