Communardo Software GmbH, Kleiststraße 10 a, D-01129 Dresden
0800 1 255 255

SharePoint-Suche: Integration von File Shares aufgepeppt (Teil 3 – Custom Entity Extraction)

Dieser Beitrag ist die direkte Fortsetzung von SharePoint-Suche: Integration von File Shares aufgepeppt (2) und zeigt eine Lösung für folgendes Problem auf:

Der Haupt-Ordner, unter dem sich eine Datei befindet (und der die einzelnen Dokumente klassifiziert), ist, wenn überhaupt, nur über die Pfadangabe (Url) im Ergebnis sichtbar. Eine Filterung des Suchergebnisses nach den einzelnen Kategorien (Hauptordnern) ist nicht möglich.

Fileshare

Als Technik werden benutzerdefinierten Entitätsextraktionsfunktionen (Custom Entity Extraction) eingesetzt.

Konfiguration eines Refiners nach Kategorie (Hauptordner)

Hier wird es nun knifflig. Was genau wollen wir eigentlich erreichen? Es soll ein Refiner erstellt werden, der zu jedem Dokument oder Ordner den Ordner auf der obersten Ebene des File Shares („Hauptordner“) zurückgibt, unabhängig davon, ob sich das Dokument direkt in diesem Ordner oder in einem Unterordner beliebiger Tiefe befindet. (Da ein klassischer Anwendungsfall für dieses Szenario jener ist, in dem der Hauptordner die Dokumente klassifiziert, bezeichne ich dies auch als „Kategorie“.)

Zuerst müssen wir wieder herausfinden, welche Managed Property dafür in Frage kommt. Genau genommen gibt es sogar mehrere, wir wollen uns auf „Path“ konzentrieren:

Codeplex Search Query Tool

Nun enthält Path aber den kompletten Pfad mit allen Ordnern und incl. Dateiname – ist also in dieser Form als Refiner ungegeignet. Hier kommt nun Custom Entity Extraction ins Spiel: SharePoint stellt insgesamt 12 vordefinierte Refiner zur Verfügung, die für 4 verschiedene Typen von Entitätsextraktionsfunktionen (Wort, Wortteil, genaues Wort, genauer Wortteil) anhand eines Dictionaries Werte einer Managed Property auf einen Dictionary-Wert mappt (Details s. oben verlinkten TechNet-Artikel). Dabei können mehrere Werte der Managed Property auf den gleichen Dictionary-Wert gemappt werden.

SharePoint-Suche: Vordefinierte Refiner für Custom Entity Extraction

Folgende Schritte sind dafür durchzuführen:

  1. Custom Entity Dictionary erstellen und für einen der 12 Custom Refiner bereitstellen
  2. Passende Managed Property konfigurieren, so dass sie den entsprechenden Custom Refiner befüllt
  3. Custom Refiner im Webpart konfigurieren

Custom Entity Dictionary erstellen und bereitstellen

Da außer den Hauptordnern beliebig viele Unterordner existieren können und die Managed Property „Path“ auch den Dateinamen mit enthält, habe ich eine „WordPart“-Extraktion gewählt. Mein Dictionary heißt „PathDictionary4.csv“, liegt im File Share (das ist purer Zufall – da hatte ich bloß schon eine Netzwerkfreigabe, und der Import erwartet einen UNC-Pfad) und sieht wie folgt aus:

Key,Display form
file://com1924915/Fileshare for Search/Case Studies/,Case Studies
file://com1924915/Fileshare for Search/SharePoint Tutorials,SharePoint Tutorials
file://com1924915/Fileshare for Search/Technische Diagramme für SharePoint 2013,Technische Diagramme für SharePoint 2013
file://com1924915/Fileshare for Search/Unterhaltsames,Unterhaltsames

Achtung, Stolpergefahr! Das Dictionary sollte als UTF-8 gespeichert werden, da ansonsten zum Beispiel Umlaute nicht korrekt gemappt werden.

Mit folgendem Powershell-Snippet wird das Dictionary für einen Custom Refiner bereitgestellt (bei mir WordPart.4, weil die anderen schon für andere Versuche in Verwendung waren):

Import-SPEnterpriseSearchCustomExtractionDictionary -SearchApplication $searchApp -Filename „\\com1924915\Fileshare for Search\PathDictionary4.csv“ -DictionaryName Microsoft.UserDictionaries.EntityExtraction.Custom.WordPart.4

SharePoint-Suche:Bereitstellung des Dictionaries für Custom Entity Extraction

In der SharePoint Management Shell sollte eine Erfolgsmeldung wie im Screenshot zu sehen ausgegeben werden.

Passende Managed Property für den Custom Refiner konfigurieren

Hier wird es nun ganz mysteriös. Eigentlich sollte die „passende“ Managed Property ja „Path“ sein, aber damit habe ich es absolut nicht zum Funktionieren bekommen, ebensowenig mit „OriginalPath“ oder „DisplayPath“. Keinerlei Fehlermeldung, weder auf der Oberfläche noch im SharePoint ULS – der Refiner enthält einfach keine Werte 😕 .

Nachdem ich der Verzweiflung schon nahe war, brachte der Blogbeitrag Entity extraction in SharePoint based on the path managed property… von von Mikael Svenson dann Licht ins Dunkel: Warum es mit Path & Co. nicht funktioniert, wird wohl das Geheimnis von Microsoft bleiben, aber folgender Trick funktioniert: 

  1. Neue Managed Property erstellen (die Eigenschaften Queryable, Refinable etc. sind unerheblich – brauchen also nicht aktiviert werden, sofern die Managed Property nicht noch für andere Zwecke verwendet werden soll)
  2. Exakt dieselben Crawled Properties wie von „Path“ auf die neue Managed Propery mappen
    • Achtung, Stolpergefahr! Es gibt mehrere Crawled Properties mit den gleichen Bezeichnungen („Basic11“ etc.), entweder man mappt kurzerhand alle oder vergewissert sich anhand der Property Set ID, dass man die richtige „erwischt“ hat.
  3. Diese Managed Property anstelle von „Path“ für den Custom Refiner verwenden

Bei mir heißt die neue Managed Property „CustomPath“:

SharePoint-Suche: Suchschema für die verschiedenen Managed Properties bzgl. Path

Nun muss nur noch die Managed Property „CustomPath“ für die Verwendung der Word Part Custom Extraction konfiguriert werden:

SharePoint-Suche: Konfiguration des Refiners "CustomPath" für Custom Entity Extraction

Zum Abschluss denken wir natürlich daran, dass ein Full Crawl erforderlich ist! 😀

Custom Refiner im Webpart konfigurieren

Das ist nun nur noch Handwerksarbeit:

SharePoint-Suche: Konfiguration des Refiners

Ergebnis anschauen und freuen 🙂

SharePoint-Suche: FileShare-Integration und Verwendung eines Refiners mittels Custom Entity Extraction

Sie wollen gleich mit der Integration von File Shares anfangen?

>> Hier gelangen Sie zu den SharePoint-Lizenzen <<

Kommentar hinterlassen


Pin It on Pinterest