Aus der Praxis: Farmweite Informationsbereitstellung mit “Search based teasering”
avatar

Da sich mein letzter Artikel um das Thema SEO drehte, möchte ich die Thematik „Suche“ auch heute nicht gänzlich verlassen und einen Mechanismus vorstellen, der auf der SharePoint-Suche basierend, Inhalte global konsolidieren und in Teaserform (Banner) darstellen kann. Ein Anwendungsfall für einen derartigen Mechanismus wäre bspw. ein Teaser wie „My Documents“ oder „My Tasks“, der auf der Mysite oder in einem zentralen Data Cockpits.

Die SharePoint-Suche als Datenbasis zu verwenden ist immer dann interessant, wenn die Ergebnisse Webanwendungsübergreifend konsolidiert werden sollen. Die Suche berücksichtigt dabei natürlich den Berechtigungskontext des jeweiligen Anwenders, so dass nur Ergebnisse präsentiert werden, auf die der User Zugriff hat.

Der Ansatz „Search based teasering“ ist derzeit bei einem Kunden im Einsatz und ist eine durchaus charmante Lösung. Aus diesem Grund möchte ich diese Komponente nachfolgend beschreiben und auf die Vor- und Nachteile eingehen.

Beschreibung der Komponente

Der Mechanismus ist derzeit in einem Webpart gekapselt und kann somit individuell in Seiten eingebunden und konfiguriert werden. Um das Webpart möglichst generisch zu halten, unterstützt der Webpart folgende Konfigurationsmöglichkeiten.

1. Teaser-Überschrift definieren

2. Selektion der Optik aus einem Set von Teasern (“My Documents”, ”My Tasks”, “My Workpackages”,  etc.)

3. Auswahl des Such-Scopes aus dem die Ergebnisse kommen sollen (Muss natürlich zu Teaser passen)

4. Eine Vorfilterung, um die  Ergebnismenge aus dem Scope zu verfeinern

5. Eine Sortierreihenfolge für die Darstellung der Suchergebnisse

6. Eine Beschränkung der Ergebnismenge auf eine max. Anzahl (Top x)

7. Angabe eines Feldes auf das in der UI zusätzlich gefiltert werden kann

image

Die Bereitstellung/Eingrenzung der dargestellten Informationen in dem Teaser ist somit über drei Schichten konfigurierbar:

1. Suchbereich (Scope):
Der Suchbereich kann bereits filtern und definieren welche Ergebnisse von welchen Quellen einbezogen werden sollen und welche explizit entfallen. Durch die Auswahl des Scopes im Webpart wird die äußerste Begrenzung der Suchergebnisse gesetzt.

2. Der Webpart-Filter:
Im Filterbereich der Webpart-Konfiguration wird die Abfrage definiert, um die Suchergebnisse aus dem Scope zu verfeinern. Bspw. kann hier die Menge der Ergebnisse so reduziert werden, dass nur noch Dokumente angezeigt werden, bei denen der aktuelle Anwender der Autor ist. Aber auch jede andere Anfrage ist denkbar.

3. UI-Filter:
In der Webpart-Oberfläche existiert ein Eingabefeld, in dem der Anwender die Treffermenge noch einmal verfeinern kann. Somit werden alle Ergebnisse, die der Webpart-Filterung genügen, erneut eingegrenzt. Dies dienst in erster Linie der Suche nach speziellen Treffern.

Sind alle Einstellungen im Webpart korrekt ausgefüllt, werden die Informationen in der selektierten Teaser-Optik tabellarisch präsentiert. Um die Übersichtlichkeit zu gewährleisten, ist ein Paging (via jQuery) integriert worden, dass mit dem zusätzlichen UI-Filter das Auffinden eines speziellen Eintrages immens erleichtert.

image

Aus rein technischer Sicht funktioniert die Lösung folgendermaßen:

Die einzelnen Felder aus den Inhaltstypen werden in so genannten „Crawled Properties“ vom SharePoint automatisch abgebildet. So genannte „Managed Properties“ bündeln die Crawled Properties für die Suche.  Dabei können mehrere Crawled Properties in einem Managed Property konsolidiert werden. D.h. die Werte aus den Inhaltstypfeldern stehen dann im Managed Property zur Verfügung.

SharePoint bringt out-of-the-box ein Set von Managed Properties mit. Zusätzliche können allerdings von Hand oder programmatisch hinzugefügt werden.

Um die Inhalte aus den Managed Properties abzufragen, sieht die Abfrage mit einer FullTextSQLQuery wie folgt aus:

Select MP1, MP2, MP3 from SCOPE() where scope = “<Scope x>” and  MP4 = “Kriterium”

Um zum Beispiel alle Dokumente der Firma HanseVision zu bekommen, müsste folgende Abfrage abgesetzt werden:

Select Title, Discription, Path, Author from SCOPE() where scope = “All Documemts” and  company = “HanseVision”

Der Ansatz, die Inhalte über die SharePoint Suche zu beziehen, ist unterm Strich sehr charmant, hat aber Vor-  und Nachteile.

Vorteile eines Suche-basierenden Ansatzes

1. Suchergebisse können farmweit konsolidiert werden. (Dies ist zugleich der einzige Weg!)

2. Berücksichtigung des Berechtigungskontext des Anwenders. (Runter bis auf Item Level Security)

3. Gute Performanz.

Nachteile eines Suche-basierenden Ansatzes

1. Die Suchergebnisse sind nur so frisch wie der letzte Crawl.

2. Konfigurationslastig und dadurch auch fehleranfällig. (Das Anlegen der Managed Properties, der Sopes und das Erstellen der Abfrage sind potentielle Fehlerquellen)

3. Ist die Informationsarchitektur nicht konsistent, hat dies gravierende Auswirkungen auf die Suche und die Ergebnismenge. Wurden bspw. Inhaltstypen von Hand angelegt, die evtl. den gleichen Namen haben oder gleichnamige aber unterschiedliche Felder referenzieren, dann kann es mitunter problematisch werden, die Informationen für den Teaser zu konsolidieren. Die Verknüpfung der Crawled – und der Managed Properties ist in diesem Fall aufwändiger.

Da die SharePoint Suche der einzige Weg ist eine farmweite Konsolidierung von Informationen zu realisieren, kam die Motivation für diese schlanke und charmante Lösung. Durch das Austauschen der Abfragelogik von FullTextSQLQuery auf KeywordQuery kann sogar mit der FAST Search interagiert werden.

Schreibe einen Kommentar