Seite 2: Suche

Inhaltsverzeichnis

Endlich richtig suchen

Die SharePoint-Suche wurde in der Vergangenheit oftmals nur mit den Standardfunktionen zum Suchen von Dokumenten oder Personen verwendet. Es ließen sich ein paar individuelle Anpassungen für das Ausgabeformat konfigurieren und ein paar Webparts für die Suche einbinden, aber die SharePoint-Suche wurde beispielsweise nur selten in Applikationen als Query Engine verwendet. In SharePoint-Applikationen oder Webparts kamen bisher primär CAML (Collaborative Application Markup Language) und LINQ (Language-Integrated Query) zum Einsatz, wenn es darum ging, Daten aus SharePoint abzufragen.

Mit SharePoint 2013 ist die Suche zur universellen Query Engine erweitert worden. Insbesondere in den Apps, die "nur" Client-Techniken verwenden können und kein CAML, LINQ oder andere Funktionen des Server Object Model, ist die SharePoint-Suche erste Wahl. Auch die Ausgabe der Suchergebnisse folgt dem Trend des clientseitigen Renderings und verwendet kein XSLT mehr, sondern JavaScript und HTML, um die Suchergebnisse mit sogenannten DisplayTemplates anzuzeigen. Das Webpart Content Search löst nun das bekannte Webpart ContentByQuery ab, über das sich Abfragen konfigurieren und die Ausgabe per SharePoint Designer/XSLT anpassen ließen (s. Abb. 5).

Im Prinzip konnten Entwickler die SharePoint-Suche schon in SharePoint 2007 auf diese Weise nutzen, indem sie per JavaScript eine Query erstellt und über den SOAP-Webservice der Suche abgesetzt haben. Das zurückgelieferte XML können sie parsen und die Darstellung entsprechend gestalten. Bei diesem Vorgehen muss man etwas "basteln", und der Zugriff über den SOAP-Webservice ist nicht unbedingt der schnellste, da das SOAP-Format viel Overhead mit sich bringt.

In SharePoint 2013 hingegen kann der Zugriff auf die Suche über das Client Side Object Model oder über die REST-Schnittstelle erfolgen. Beide Varianten haben Vor- und Nachteile, je nachdem in welchem Hosting-Szenario für Apps man sie einsetzen möchte (SharePoint-Hosted, Autohosted oder Provider-hosted). Die Kombination von REST und JavaScript ist in den meisten Fällen die effizienteste, da sie das "schlanke" JSON-Format zurückliefert, und kann zum Beispiel in Windows-8- oder Office-2013-Apps verwendet werden. Der folgende Quellcode zeigt einen REST-Aufruf der SharePoint-2013-Suche, der ähnlich im ersten Artikel beim SharePoint-App-Beispiel genutzt wurde.

function Search()
{
[...]
var url = "http://server/site/_api/search/query?querytext='test'&
      selectproperties='Title,Rank'";
$.ajax(
        {
            url: url,
            method: "GET",
            headers: {
                "accept": "application/json;odata=verbose",
            },
            success: Results.onSuccess,
            error: Results.onError
        }
    );
[...]
}

Da die Funktionen der SharePoint-Suche, unter anderem wegen der Integration der FAST-Search, erweitert wurden, sollte man sich zu den folgenden Komponenten Gedanken machen, wenn man Suchapplikationen entwickeln möchte:

• Ergebnisquellen: lokaler SharePoint-Index, Exchange, OpenSearch etc.
• Abfrageregeln werden auf Ergebnisquellen angewendet und unter definierten Bedingungen ausgeführt. Sie beeinträchtigen die Abfrage-Ergebnisse.
• Ergebnistypen sind an Ergebnisquellen gebunden und werden per Regel definiert. Sie sind mit einem sogenannten DisplayTemplate beziehungsweise einer Anzeigenvorlage assoziiert.

Ein wichtiger Aspekt der SharePoint-Suche ist, dass sie zwar schnell Ergebnisse findet, da die SharePoint-Inhalte indiziert sind, aber die Ergebnisse nur so aktuell wie der Suchindex sind. Das heißt, wenn man nur einmal am Tag die Inhaltsdatenbanken und Suchquellen indiziert, wird der Suchindex nur täglich einmal aktualisiert. Diese Suchmethode eignet sich also nicht, wenn man "Echtzeit"-Daten abfragen möchte.

Im einfachsten Fall genügt es erst einmal für die Suche, die DisplayTemplates anzupassen. Die Anzeigevorlagen bestimmen, wie ein bestimmter Inhaltstyp ein Element darstellt. Das können Elemente in einer Liste, Diskussion, Bibliothek oder Suchergebnisse eines bestimmten Typs sein. Listing 1 zeigt das HTML-DisplayTemplate für ein Default-Item. Falls der Entwickler die Darstellung anpassen möchte, kann er die HTML-Datei entsprechend ändern.