Integration eines Dateisystem-Index in die Liferay 7 Suche

Gerade in großen Unternehmen gibt es immer eine umfangreiche Menge von Dokumenten die auf verschiedenen Netzwerklaufwerken Mitarbeitern zu Verfügung stehen. Das händische Suchen des richtigen Dokuments darin ist dann oft mühsam und zeitaufwendig. In diesem Artikel beschreibe ich unseren Ansatz zur Integration dieser Dokumente in die Standardsuche von Liferay 7.

Für einen unserer Kunden realisieren wir zur Zeit eine auf Liferay 7 basierende Intranet-Lösung. Neben typischen Funktionen, wie Content Management, Blogs und Wikis gibt es hier auch eine etwas speziellere Anforderung: die Mitarbeiter nutzen einen Fileserver zur Ablage aller wichtigen Dokumente und wünschen sich eine Integration dieser Dateien in die Suche der neuen Plattform.

Wie auch die Umsetzung dieses Projekts, basiert ein erheblicher Teil unserer Lösungen auf Liferay Portal, einer Enterprise Portal Software, die in Java realisiert ist. Liferay bietet von Haus aus eine Suchfunktion, die alle relevanten Informationen zu vorhandenen Inhalten, wie Webcontent oder Blogartikeln inhaltlich erfasst und über die Suchmaske in der Oberfläche bereitstellt. Im Hintergrund verwendet Liferay dazu ElasticSearch, eine Volltext-Indizierungs-Engine, die hochperformant ist und individuelle Anfragen, aber auch detaillierte Analysen auf den indizierten Daten erlaubt. Um eine perfekte Integration in die Plattform des Kunden zu erreichen, ist es naheliegend auch die Informationen aus dem Dateisystem in die von Liferay verwendete ElasticSearch Instanz zu schreiben, genauer gesagt, einen weiteren von Liferay erfassbaren Index bereitzustellen und so alles in die vorhandene Standard Suche einzubetten.

Für gewöhnlich sind die von Liferay indizierten Inhalte in irgendeiner Form in der Datenbank hinterlegt, z.B. als Implementierung eines Assets oder als einfache Entität. Da der Umfang des Fileservers bei mehr als 300.000 Dateien liegt und ein Datenvolumen von über einem Terrabyte hat, war es für uns nicht zielführend hierfür eine eigene Asset-Implementierung zu entwickeln und sämtliche Informationen auch zusätzlich in der Datenbank abzulegen. Stattdessen wollten wir nur die Metadaten und den Text-Inhalt aller gefundenen Dateien im Index hinterlegen und so aufbereiten, dass sie von der Liferay-Suche direkt gefunden und angezeigt werden können.
Um Liferay mit allen notwendigen Informationen zu beliefern benötigen wir zudem eine Anwendung, die in der Lage ist das Dateisystem, ein im Server gemountetes Windows Share, vollständig zu durchsuchen, die gefundenen Meta-Informationen aufzubereiten und via Webservice zu übergeben. Nach dieser initialen Indexierung muss die Anwendung aber auch in der Lage sein sämtliche Änderungen, die von nun an im Dateisystem stattfinden zu erkennen und ebenfalls sofort in Liferay verfügbar zu machen.

Beides zusammen soll so performant sein, dass aus Sicht der Anwender ein immer konsistentes Abbild aller Dateien des Fileservers in der Suche existiert.

Dateisystemmonitor

Die Umsetzung des Dateisystemmonitors, in unserem Fall eine Java Spring Boot Anwendung basiert auf Java NIO Files zur Umsetzung der initialen (oder Re-)Indizierung, also dem Auffinden der vorhandenen Dateien sowie dem Apache Commons Virtual File System um im späteren Verlauf Änderungen im Dateisystem zu erkennen.
Die Umsetzung der vollen (Re-)Indizierung ist denkbar einfach. Mit java.nio.Files kann der Zielpfad durchlaufen und für jede gefundene Datei ein Update auf den Liferayindex generiert werden. Dank Lambda Ausdrücken und Streams in Java können hier auch gleich übersichtlich Filterfunktionen integriert werden.

Die Klasse DefaultFileMonitor aus der Commons-VFS Bibliothek kann zum weiteren Beobachten des Dateisystems genutzt werden und bietet ein simples Programmierinterface: es können Eventhandler für alle typische Operationen im Dateisystem registriert werden, z.B. Anlage, Änderung oder Löschen einer Datei. Die eigentliche Erkennung wird vollständig durch den DefaultFileMonitor übernommen, und das impliziert alle umgebungsspezifischen Details, also die vom System gemeldeten Änderungen (genauer gesagt: die geworfenen Events) die in einer eigenen Implementierung erst abhängig von Betriebs- und Dateisystem individuell interpretiert werden müssten. Nicht zuletzt kann die Apache Implementierung auch problemlos auf Netzlaufwerken, z.B. via Samba-Share arbeiten.

Für die inhaltliche Indizierung der gefundenen Dateien kann Apache Tika verwendet werden. Tika ist in der Lage den Typ einer Datei, z.B. Word, Excel oder PDF weitestgehend selbstständig zu erkennen, den eigentlichen Inhalt des Dokuments und verfügbare Metadaten zu extrahieren und als Plain Text bereitzustellen. Tika unterstützt dabei über tausend typische Formate (eine Übersicht kann hier eingesehen werden), darunter auch exotischere Anwendungsfälle, wie das Extrahieren von Metadaten aus Bildern, Audio- oder Videodateien, Cryptoformate oder Datenbankdateien.
Der Einsatz von Tika ist ebenfalls unkompliziert: es wird eine AutoDetectParser Instanz benötigt der beim Aufruf der Methode parse(…) u.a. der InputStream eines passenden Dokumentes, ein Metadata Objekt und eine BodyContentHandler Instanz übergeben werden müssen. Ist Tika fertig, kann über die Instanz des Handlers das Ergebnis der Extrahierung abgefragt werden.

Index für die Liferay Suche

Um die Informationen aus dem Dateisystem in der Liferaysuche verfügbar zu machen muss eine Implementierung des Indexer Interfaces (com.liferay.portal.kernel.search.Indexer) bereitgestellt werden. Liferay bietet eine Basisklasse BaseIndexer die erweitert und auf das lokale Java Objekt welches unsere Dokumente des Fileservers repräsentiert typisiert werden kann. So muss nicht das volle Interface von immerhin 37 Methoden selbst implementiert werden. Mit der Implementierung des Indexers können dann Dokumente im Index hinterlegt werden.

Das vom Dateimonitor, z.B. per Webservice übergebene Objekt muss zunächst in ein Liferay Document überführt werden und kann dann mit Hilfe des IndexWriterHelperUtil in den Index geschrieben werden. Ein Liferay Document besteht im wesentlichen aus einer Map mit Key-Value Paaren, welche die zu indizierenden Felder darstellen. Durch Überschreiben weiterer Methoden kann die Suche individualisiert werden, z.B. mit postProcessSearchQuery() um weitere Felder bei der Suche durch Liferay berücksichtigen zu lassen oder getClassName() um einen sprechenden Namen für die Ergebnisse in der Suche, z.B. den Facetten zu liefern. Damit Liferay weiß, wie die Suchergebnisse aus dem Index darzustellen sind, muss zuletzt noch eine AssetRendererFactory bereitgestellt werden. Auch hierfür gibt es wieder eine Basisklasse, BaseAssetRendererFactory die ebenfalls erweitert und typisiert werden kann. Falls notwendig kann hier auch ein eigener AssetRender, z.B. auf JSP Basis geschrieben werden. So lässt sich die Darstellung in den Suchergebnissen weiter individualisieren.

Fazit

Die Metainformationen eines Dateisystems können mit Bordmitteln von Java NIO und Apache Commons VFS unkompliziert indiziert und weiter beobachtet werden. Die Inhalte von Dokumenten lassen sich mit Apache Tika für eine Vielzahl von Dateiformaten über eine einheitliches Interface erfassen. Für die Integration in die Liferay-Suche muss ein neuer Index und ein passendes AssetRendering implementiert werden. Alles in allem ist das sehr wenig Aufwand für eine Funktionalität die einen echten Mehrwert in einem Intranet darstellen kann, wo Mitarbeiter sonst immer wieder manuell Fileserver durchsuchen müssen.

Wichtig ist bei einer solchen Integration jedoch eine Analyse der Dateien, die auf den Laufwerken gespeichert wurden. In unserem Fall haben wir uns z.B. gemeinsam mit dem Kunden entschieden, ausschließlich Office-Dokumente und PDF-Dateien auch inhaltlich zu indizieren, um u.a. eine bessere Performance zu erreichen. Alle anderen Datei-Formate indizieren wir „nur“ mit Ihrem Dateinamen und den Basis-Metadaten aus dem Dateisystem, die auch ohne Apache Tika extrahiert werden können. Weiterhin haben wir eine Beschränkung der inhaltlich indizierten Dokumente auf maximal 15 MB Dateigröße gesetzt, da wir in der Analyse auf zahlreiche Dokumente gestoßen sind, die zwar mehrere hundert MB groß waren, inhaltlich aber nur aus Bildern bzw. Werbe-Materialien bestanden. Diese Dokumente hatten inhaltlich keine große Relevanz für den Such-Index und konnten somit ausgeschlossen werden. Eine solche vorherige Analyse lässt sich gepaart mit dem fachlichen Wissen des Kunden sehr gut mit den beschriebenen Tools umsetzen.

Weiterführende Infos:

• https://commons.apache.org/proper/commons-vfs/
• https://dev.liferay.com/de/develop/tutorials/-/knowledge_base/7-0/search
• https://www.elastic.co/de/products/elasticsearch
• https://tika.apache.org/
• Informationen zum Liferay Portal
• Informationen zu Web-Portalen allgemein

Wünschen Sie weitere Details oder haben Sie konkrete Fragen?

Vereinbaren Sie einfach einen Beratungstermin mit uns. Gerne präsentieren wir Ihnen den Funktionsumfang von Liferay 7 und der Portal-Suche in einer Live-Demo.