Montag, 28. Mai 2012

Eigene Sortierreihenfolge in der SharePoint Suche


Custom sort option in SharePoint Search Results

Der Post basiert auf einer Frage aus der Community. Ich fand das wäre auch einen Blog Post wert.

Die Frage lautet: Ein Kunde hat folgende Anforderung: das Core-Results WebPart der SharePoint 2010 Suche kann nach Relevanz und Datum sortieren. Die Idee des Kunden ist nun, selbst ein Core Results WebPart zu schreiben um nach weiteren Eigenschaften die Sortierung selbst zu machen. – ist das eine gute Idee? Was ist dabei zu beachten?

Das ist eine gute und viel diskutierte Frage. Es gibt bereits einige Ansätze dazu in Netz, z.B. hier:


oder dieses Webpart:




alles in allem funktioniert das also schon. Mit jQuery kann man da auch handanlegen. Das Problem bei all diesen Lösungen ist, dass die Sortierung im Client gemacht wird. Das kann, je nach Datenmenge, zu einer sehr schlechten Performance führen und belastet eben den Client.

Wenn man solch eine Lösung als ein SharePoint Feature realisiert, dass dann auf dem AppServer läuft, hat man die Last vom Client zumindest schon mal auf einen skalierbaren Server verlegt. Der Punkt ist, dass das Resultset in beiden Fällen erst mal vom SQL Server geladen werden muss, dann umsortiert wird, und dann angezeigt wird. Die Lösung mit einem Feature ist natürlich schon mal besser zu skalieren als eine Lösung im Client.

Die Tatsache, warum die Suche nur die beiden Sortieroptionen „Relevanz“ und „Datum“ anbietet hat natürlich ihren  Grund. Die StoredProc proc_MSS_GetMultipleResults liefert das ganze SQL-seitig nach Relevanz sortiert (Details siehe hier: LINK). Eine nachträgliche Sortierung nach Datum ist einfach zu machen und kostet nicht viel Rechenzeit. Alles andere kann beliebig ausarten, vor allem bei größeren Datenmengen.

Ich plädiere dafür die Sortierung im SQL Server zu machen. Der kann das am besten, und um Längen besser und performanter als .net. Das ist recht einfach zu machen wenn das Property nachdem sortiert werden soll eines der folgenden ist: Rank, Title, Author, Size, Path, Write, HitHighlightedSummary, HitHighlightedProperties. Diese kommen im Result vom SQL Server standardmäßig mit. Der Call der an den SQL Server geht sieht in etwa so aus:

<QueryText language="en-US" type="MSSQLFT">Select PopularSocialTags,Rank, Title, Author, Size, Path, Write, HitHighlightedSummary, HitHighlightedProperties FROM Scope() WHERE FREETEXT(DefaultProperties, '%searchTerm%') ORDER BY "Rank" DESC</QueryText>

ORDER BY ist hier also einfach anzupassen. Wenn es eigene Properties sein sollen wirds komplizierter. Eine gute Möglichkeit damit zu experimentieren ist das Tool: http://fastforsharepoint.codeplex.com/ (heißt zwar FAST, geht aber auch für die normale Suche). Dort kannst das XML, das an den Webservice der Suche geschickt wird, bearbeitet werden und man kann damit experimentieren…

…Der offizielle Weg wäre FAST zu nehmen und ein eignes Rankingprofil zu erstellen.

Keine Kommentare:

Kommentar posten