Die Nadel im Heuhaufen - Intranet Suche

Suchtechnologien, die im Internet genutzt werden, sind auch für das firmeninterne Netzwerk bzw. Intranet interessant. Denn auch dort sind oft Ressourcen zu einem Thema auf verschiedenen Systemen verteilt. Verteilte Umgebungen dieser Art sind dabei viel häufiger und natürlicher als zentralistische Systeme, die sämtliche Ressourcen auf einem einzigen Rechner zu sammeln versuchen. Dann stellt sich für Mitarbeiter:innen aber die meist schwierige Frage, wo nach Informationen und Dokumenten zu einem bestimmten Thema zu suchen ist. Im besten Fall haben sie zumindest einen ersten Anhaltspunkt und finden dort weitere Verweise, denen sie nachgehen können. Das ist aber in der Regel sehr unzuverlässig und verlangt von den Autor:innen der Dokumente einen hohen Einsatz, andere Dokumente zu verlinken, wenn sie ihnen bekannt werden.

Wir haben uns mit der Möglichkeit beschäftigt, Intranet Search Engines als übergreifende Suche auf unserem Firmennetzwerk zur Verfügung zu stellen, um verteilte Ressourcen zu einem Thema leichter auffindbar zu machen. Dies ist ein Bericht darüber.

Quellsysteme auf dem Intranet

Auch auf unserem Intranet sind Ressourcen über verschiedene Systeme verteilt, zum Beispiel.:

• Confluence, ein Wiki, das besonders vom Technologiebereich genutzt wird
• SharePoint und Alfresco sind Dokument- und Kollaborationsplattformen, wo Dokumente, Vorträge, Videos und vieles mehr abgelegt werden
• Bitbucket hält einen Großteil unseres Source Codes
• in Jira werden Aufgaben und Probleme für die Technik dokumentiert
• einem Ticket System, in dem sowohl der Support wie die IT ihre Tickets verwalten

Während das Wissensmanagement zur Zeit an der notwendigen Konsolidierung der übergreifenden Ablagesysteme arbeitet, wäre es doch auch schön, all diese Systeme bequem von einem „Suchschlitz“ aus durchsuchen zu können. Das wäre eine übergreifende Suche.

Suchtechnologien

Internet Search Engines (ich bleibe hier mal bei der englischen Bezeichnung, sonst landen wir bei "Globalnetzsuchapparaten") kommen in zwei Geschmacksrichtungen. Klassische Search Engines bestehen aus mehreren Komponenten. Ein Crawler holt, ähnlich einem normalen Browser, Seiten von Web Servern und legt sie lokal ab. Diese Seiten werden dann nach weiteren Links durchsucht, die der Crawler dann wieder vom Netz holen kann. Währendessen analysiert eine andere Komponente, oft Indexer genannt, die abgelegten Seiten, extrahiert interessante Suchbegriffe und legt sie zusammen mit der URL der Seite in einem Index ab. Das könnte eine Datei, mehrere Dateien im Dateisystem oder eine Datenbank sein. Klassische Search Engines machen dann Sinn, wenn man Websites durchsuchen möchte, die keine oder keine gute eigene Suche bieten, oder wenn eine große und/oder unbekannte Anzahl von Websites durchsucht werden soll, deren Webseiten in der Regel mit Links im HTML Code verknüpft sind. Die Google Suche ist natürlich der bekannteste Vertreter dieser Search Engine Art. Die Technik wird auch eingesetzt, um lokale Systeme zu indizieren und eine Suche für sie zur Verfügung zu stellen, zum Beispiel bei Wikis, Content Management Systemen, grossen Firmenwebsites und so weiter.

Klassische Search Engines arbeiten asynchron, weil sie Ergebnisse auf Suchanfragen aus ihrem Index beantworten, der ja auf der Grundlage von Seiten erstellt wurde, die in dieser Form vielleicht gar nicht mehr online sind. Der Crawler muss desshalb immer wieder losgeschickt werden und neben neuen auch Seiten holen, die er schon einmal geholt hat, um Seitenänderungen mitzubekommen. Der Vorteil auf der anderen Seite ist, dass die Search Engine eine gewisse Unabhängigkeit von der Verfügbarkeit der Quellsysteme hat und, wie im Beispiel von Google, auch komplette Seiten aus ihrem eigenen Cache anzeigen kann, wenn der Originalserver mal nicht verfügbar ist. Anforderungen an die Speicherkapazität, CPU-Leistung und Bandbreite können - je nach Anzahl der Nutzer:innen und der indizierten Webseiten - astronomisch hoch werden (wie man auch an Google sieht).

Eine (immer noch) bestehende Achillesferse dieser Search Engines ist ihre Abhängigkeit von den Links im Quellcode der heruntergeladenen Webseiten. Ohne diese Links werden keine neuen Seiten gefunden und es gibt dann keinen Fortschritt im Umfang der indizierten Seiten. Moderne Webseiten bestehen aber aus immer weniger HTML Code, der Links enthält. Vielmehr lädt der HTML Code nur weitere JavaScript Dateien nach, und erst durch deren Ausführung entstehen die Links, die der normale Benutzer im Browser vor sich sieht. Ein Crawler benutzt aber in der Regel keinen Browser, um die Seiten herunterzuladen, das wäre zu langsam und zu umständlich. Aber es gibt kaum Software, die JavaScript ausserhalb des Browsers so ausführt, dass bei einer dynamischen HTML Seite ein kompletter DOM (eine interne Repräsentation der Seite) erstellt wird, aus dem dann die Links extrahiert werden könnten. Ehrgeizige Junior Entwickler:innen können hier noch zu Ruhm und Ehre gelangen.

Die andere Sorte von Search Engines sind Meta-Search Engines. Sie "crawlen" nicht und bauen daher auch keinen eigenen Suchindex auf. Vielmehr leiten sie Suchanfragen direkt an andere Search Engines weiter, nehmen deren Ergebnisse entgegen und zeigen sie in einer zusammengefassten Form an. Die Meta-Search Engine arbeitet synchron, sie hält keine eigenen Daten, sondern holt sie in dem Moment von den nachgelagerten Quellsystemen ab, in dem eine Anfrage gestellt wird. So können Meta-Search Engines die Ergebnisse mehrerer anderer Search Engines akkumulieren, sortieren und gruppieren. Dabei ist es unerheblich, ob die angefragten Systeme ihrerseits klassische Search Engines sind, die fremde Webseiten untersucht haben, oder Systeme, die ihre eigenen, lokalen Ressourcen per Suchschnittstelle zur Verfügung stellen (zum Beispiel Content Management Systeme).

Meta-Search Engines machen dann Sinn, wenn man eine begrenzte, vorab bekannte Anzahl von Quellsystemen durchsuchen möchte, die ihrerseits Such APIs anbieten. Im Internet ist neben der Akkumulation der verschiedenen Ergebnisse auch der Schutz der Privatsphäre (gegen Search Tracking) ein wichtiges Motiv, Meta-Search Engines zu benutzen.

Der Prototyp

Wir haben einen Prototyp für eine übergreifende Suche auf einer Linux VM umgesetzt. Als Technologien setzten wir ARCH als klassische Search Engine ein, und SearX als Meta-Searcher. Wir nutzten die Crawler-basierte Search Engine, um klassische, HTML-basierte Systeme anzubinden und Network Shares, die wir über einfache Static-File Webserver wie Lighttpd oder Nginx erreichbar machten. Der Vorteil bei dieser Art von Search Engines ist es auch, dass neue Systeme auf dem Intranet automatisch gefunden werden, wenn sie in einem bereits bekannten Bereich verlinkt wurden. Dazu reicht schon eine Ankündigung im RSS Feed eines zentralen Servers.

Diesem System schalteten wir die Meta-Search Engine als vorgelagertes System vor. Damit wurde die Meta-Search Engine zum "Single Point of Entry". ARCH erschien darin wie ein weiteres Quellsystem, hinter dem sich in Wirklichkeit mehrere andere Systeme verbargen. Weitere Systeme, die hier angesschlossen wurden, waren solche, die zu stark auf JavaScript für die Seitenverlinkung setzen.

Das grosse Problem: Berechtigungen auf Ressourcen

Neben der Problematik, bei jedem Quellsystem eine gute Such API zu finden, war die Haupthürde, mit der wir zu kämpfen hatten, dass viele Systeme Seiten hinter qualifizierten Logins verbergen. So blieben entweder nur die öffentlichen Seiten übrig, oder auch gar nichts, wenn ein System schon die Eingangsseite durch ein Login schützt. Ein Lösung wäre, auf der Ebene der Meta-Search Engine User Profile anzulegen, wo jeder Nutzer seine Credentials für die verschiedenen Quellsysteme hinterlegen kann, die dann für authentifizierte Suchen in den jeweiligen Systemen von der Search Engine genutzt werden. Das könnte zu sehr guten, personalisierten Suchergebnissen führen. Leider haben wir in der gegebenen Zeit keine Software gefunden, die das ermöglicht.

Alternative Optionen wären, mit der IT spezialisierte Zugänge für die Search Engines auf den jeweiligen Quellsystemen bereitzustellen, zum Beispiel dedizierte Access Tokens. Dann hätten die Search Engines die Möglichkeit, größere Mengen von Seiten zu durchsuchen und dadurch mehr Treffer zu finden. Nachteil wäre aber, dass alle User auf die gleiche Anfrage die gleichen Suchergebnisse bekämen, unabhängig davon, ob sie sie in jedem Fall auch ansehen dürfen, wenn ihre Zugriffsberechtigung für das jeweilige Dokument nicht ausreicht. Trotzdem würde so die Existenz dieser Dokumente öffentlich.

Zusammenfassung

Zusammenfassend kann man sagen, dass eine unternehmensweite (übergreifende) Suche einen hohen Mehrwert bieten kann, wobei sowohl klassische, Crawler-basierte wie Meta-Search Engines in Kombination zum Einsatz kommen.

Der Aufwand an Investitionskosten kann durch Open-Source Lösungen und VMs sehr gering gehalten werden. Die eigentlichen Aufwände stecken im Anschliessen der verschiedenen Quellsysteme. Neben recht unterschiedlichen APIs sind die verschiedenen Logins die größte Hürde, um für einen Benutzer relevante Ergebnisse bereitstellen zu können.