Lucene-Handbuch deutsch

Transcription

LuceneConnectorManual_de.book Page 1 Tuesday, May 16, 2006 4:51 PM
Livelink WCM Server
Search Server Connector für
Lucene-Handbuch
Dieses Handbuch beschreibt die Konzepte und
Verwaltung von Lucene-Suchservern. Sie
erhalten Informationen zu folgenden Themen:
• technische Grundlagen von LuceneSuchservern
• Verwalten von Lucene-Suchservern im
Admin-Client
• Index- und Query-System von LuceneSuchservern einschließlich
Programmierbeispielen
• Abfragesyntax von Lucene
Copyright 2006 Open Text Corporation
Das Copyright an diesen Unterlagen und der dazugehörigen Software gehört ohne
Einschränkungen der Open Text Corporation. Diese Unterlagen und die dazugehörige
Software dürfen ohne die ausdrückliche, schriftliche Genehmigung der Open Text
Corporation weder ganz noch teilweise kopiert werden.
Die Open Text Corporation ist Eigentümer der Warenzeichen Open Text, ’Great Minds
Working Together’, Livelink, MeetingZone u.a.; diese Liste ist nicht vollständig. Andere in
der Dokumentation erwähnte Warenzeichen sind Eigentum des jeweiligen Unternehmens
und werden nur zum Zweck der Identifizierung der Produkte und Unternehmen
verwendet. Alle Rechte vorbehalten.
Für die in diesem Dokument beschriebene Software der Open Text Corporation gelten
bestimmte Gewährleistungen und Einschränkungen. Informationen zu diesen
Gewährleistungen und Einschränkungen erhalten Sie in dem Lizenzvertrag, der zwischen
dem Lizenznehmer und der Open Text Corporation geschlossen wurde.
Kontaktadresse:
Unternehmenshauptsitz
Open Text Corporation
275 Frank Tompa Drive,
Waterloo, Ontario
N2L 0A1
Kanada
Telefon: +1 519 888-7111
Wenn Sie Abonnent des Customer Assistance Program sind oder weitere Informationen zum
Kundendienstprogramm wünschen, wenden Sie sich an den Kundendienst von Open Text
Corporation unter [email protected] oder per Telefon unter +1 (800) 540-7292 oder +1
(519) 888-9933. Unser Kundendienst ist Montag-Freitag von 8:30 Uhr bis 20:00 Uhr (EST)
erreichbar.
Wenn Sie zu dieser Dokumentation Anmerkungen haben oder Vorschläge machen möchten,
senden Sie eine E-Mail-Nachricht an [email protected].
Weitere Informationen zu den Produkten und Dienstleistungen der Open Text Corporation
finden Sie auf unserer Homepage unter http://www.opentext.com.
© 2006 IXOS SOFTWARE AG
Werner-v.-Siemens-Ring 20
85630 Grasbrunn, Deutschland
Tel.: +49 (89) 4629-0
Fax: +49 (89) 4629-1199
E-Mail: [email protected]
Internet: http://www.ixos.com
Alle Rechte vorbehalten. Einschließlich solche, die die Reproduktion, das Kopieren oder eine
andere Verwendung oder Übermittlung der Inhalte dieses Dokumentes oder Teile davon
betreffen. Kein Teil dieser Publikation darf, egal in welcher Form, ohne die schriftliche
Zustimmung der IXOS SOFTWARE AG reproduziert, an Dritte übermittelt, unter Einsatz
elektronischer Retrieval-Systeme verarbeitet, kopiert, verteilt oder für öffentliche
Vorführungen verwendet werden. IXOS behält sich das Recht vor, Aktualisierungen und
Änderungen der Inhalte vorzunehmen. Sämtliche Daten, die auf Bildschirmfotos
(screenshots) sichtbar sind, dienen lediglich als Beispiel zur Demonstration der Software.
Für den Inhalt dieser Daten übernimmt IXOS keine Gewähr. Dieses Produkt beinhaltet
Software, die im Rahmen des Projekts OpenSSL für den Gebrauch im OpenSSL Toolkit
(http://www.openssl.org/) bzw. die durch die Apache Software Foundation (http://
www.apache.org/) entwickelt wurde.
Marken IXOS: IXOS SOFTWARE AG.
SAP® , R/3® und SAP ArchiveLink® sind eingetragene Marken der SAP AG.
Microsoft®, Microsoft Windows NT ® und die Namen weiterer Microsoft-Produkte sind
eingetragene Marken der Microsoft Corporation.
Acrobat Reader Copyright © 1987 Adobe Systems Incorporated. Alle Rechte vorbehalten.
Adobe und Acrobat sind Marken von Adobe Systems Incorporated, die in bestimmten
Rechtsbereichen registriert sein können.
Siebel® ist eingetragene Marke der Siebel Systems, Inc.
Sonstige Produktnamen werden nur zur Identifikation der Produkte verwendet und können
eingetragene Marken der entsprechenden Hersteller sein.
Copyright © 2006 Gauss Interprise AG Hamburg, Gauss Interprise, Inc.
Irvine, California. Alle Rechte weltweit vorbehalten.
Dieses Dokument sowie die zugehörige Software sind Eigentum der Gauss Interprise AG
oder ihrer Zulieferer und durch Gesetze zum Schutze des Urheberrechts und andere Gesetze
geschützt. Sie werden unter einer Lizenz vertrieben, durch welche die Nutzung,
Reproduktion, Vertrieb und Dekompilierung eingeschränkt wird. Weder der Erhalt noch der
Besitz dieses Dokumentes ermächtigt Sie, dessen Inhalte ganz oder teilweise auf Papier,
elektronisch oder einem anderen Medium zu reproduzieren, weiterzugeben oder anderen
den Zugang darauf zu ermöglichen. Kein Teil dieses Dokumentes darf in irgendeiner Form
und Weise ohne vorherige schriftliche Zustimmung der Gauss Interprise AG oder Gauss
Interprise, Inc. reproduziert werden.
Darüber hinaus gelten für diese Dokumentation die Bestimmungen des
Softwarelizenzvertrags.
Alle Warenzeichen oder Handelsmarken, die in diesem Dokument erwähnt wurden, sind
Eigentum der entsprechenden Firmen.
http://www.opentext.com/bridging/gauss.html
Programmversion: Livelink Web Content Management ServerTM (Content Server) 9.5.1
Dokumentenversion: De-01
Erscheinungsdatum: Mai 2006
Inhaltsverzeichnis
Abbildungsverzeichnis
6
Tabellenverzeichnis
7
Kapitel 1
9
Allgemeine Hinweise
1.1
Kapitel 2
Kapitel 3
Kapitel 4
4
Willkommen beim Search Server Connector
für Lucene
9
1.2
Hinweise zu diesem Handbuch
10
1.3
Typographische Konventionen
12
Konzepte
15
2.1
Allgemeine Funktionsweise
15
2.2
Index-System
18
2.3
Query-System
20
2.4
Systemarchitektur
21
Lucene-Suchserver verwalten
27
3.1
Lucene-Suchserver konfigurieren
28
3.2
Lucene-Suchserver in der Systemverwaltung
38
3.3
Die Datei contentminer.xml
42
Index-System
51
4.1
Synchronisieren
51
4.2
Kommandozeilen-Tools
53
4.3
File-Handles
65
Livelink WCM Server
Kapitel 5
Query-System
67
5.1
Einfache Suche ausführen
68
5.2
Konfigurationsdaten verwenden
72
5.3
WCM-System in das Ergebnis der Suchanfrage
integrieren
76
Anhang A
Abfragesyntax
85
Anhang B
Nicht unterstützte Funktionen des
Content Miner-API
95
Glossar
Index
Search Server Connector für Lucene – Handbuch
99
103
5
Abbildungsverzeichnis
Abb. 1 –
Zuordnung von mehreren Suchservern zu einem
Content-Server
17
Abb. 2 –
Beteiligte Komponenten beim Erzeugen eines Index
19
Abb. 3 –
Beteiligte Komponenten beim Verarbeiten einer Suchanfrage
20
Abb. 4 –
Integration von Suchservern in ein WCM-System
24
Abb. 5 –
Die Elemente der Konfiguration
28
Abb. 6 –
Übersicht über die installierten Suchserver in der Ansicht
Konfiguration
29
Abb. 7 –
Einstellungen eines Lucene-Suchservers
30
Abb. 8 –
Neue interne Collection anlegen
32
Abb. 9 –
Wurzelobjekt und Objekttypen festlegen
33
Abb. 10 –
Darstellung einer internen Collection in der baumartigen
Ansicht
34
Abb. 11 –
Neue externe Collection anlegen
35
Abb. 12 –
Darstellung einer externen Collection in der baumartigen
Ansicht
36
Abb. 13 –
Einstellungen einer Collection
37
Abb. 14 –
Die Elemente der Systemverwaltung
38
Abb. 15 –
Übersicht über die installierten Suchserver in der
Systemverwaltung
39
6
Livelink WCM Server
Tabellenverzeichnis
Tabelle 1 –
Einträge in der Datei contentminer.xml
44
Tabelle 2 –
Allgemeine Parameter der Kommandozeilen-Tools
56
Tabelle 3 –
Parameter des Kommandozeilen-Tools AddDocument
58
Tabelle 4 –
Parameter des Kommandozeilen-Tools DeleteDocument
59
Tabelle 5 –
Parameter des Kommandozeilen-Tools AddDirectory
61
Tabelle 6 –
Parameter des Kommandozeilen-Tools DeleteDirectory
62
Tabelle 7 –
Verknüpfungsoperatoren in Suchanfragen
90
Tabelle 8 –
Unsupported Operations
95
7
8
Livelink WCM Server
KAPITEL 1
Allgemeine Hinweise
1
Dieses Kapitel bietet Ihnen einen ersten Überblick über die Funktionalität
des Search Server Connector für Lucene. Außerdem wird der Aufbau
dieser Dokumentation beschrieben und weitere Hinweise zum Dokument
gegeben.
1.1 Willkommen beim Search Server
Connector für Lucene
Eine Website kann Tausende von HTML-Seiten und anderen Dokumenten
enthalten. Die Suche nach bestimmten Informationen bzw. Inhalten in
einer Website ist deshalb unter Umständen sehr mühsam und zeitaufwendig. Mithilfe der leistungsfähigen Volltextsuchmaschine Jakarta
Lucene aus dem Open-Source-Projekt Apache finden Sie schnell und
komfortabel Seiten und Dokumente, die die von Ihnen eingegebenen
Wörter beinhalten.
In Kombination mit Livelink Web Content Management ServerTM (kurz:
Livelink WCM Server) bietet der Search Server Connector für Lucene
außerdem die sehr nützliche Option, nur solche Dokumente im Suchergebnis aufzulisten, für die der anfragende Benutzer die erforderliche
Leseberechtigung hat. Auf diese Weise bleiben Ihre Daten vor unberechtigten Zugriffen geschützt.
9
Kapitel 1
1.2 Hinweise zu diesem Handbuch
Der Search Server Connector für Lucene und damit auch dieses Dokument richten sich an Personen, die über fundiertes technisches Know-how
verfügen. Die folgenden Voraussetzungen sollten erfüllt sein:

Kenntnis des Produkts Livelink WCM Server, möglichst nicht nur als
Anwender, sondern als Administrator

technisches Verständnis für die Abläufe bei der Benutzung von JavaServer-Pages (JSP) und Servlets

allgemeine Programmiererfahrung, Erfahrung in der Programmierung mit Java und Kenntnisse über HTML
Zusätzlich zum vorliegenden Handbuch können Sie Informationen aus
folgenden Quellen beziehen:

Livelink WCM Server-Administratorhandbuch – Dieses Dokument
weist Sie ausführlich in alle Aufgaben der Systemadministration ein.
Es enthält auch wichtige Hinweise zum Aufbau und zur Konfiguration
eines WCM-Systems.

WCM Java API-Programmierhandbuch: Dieses Dokument enthält
Informationen über Interfaces, Klassen und Methoden der JavaProgrammierschnittstelle (WCM Java API), mit der die Funktionalität
der WCM-Server über externe Programme genutzt werden kann.

Javadoc – Hier finden Sie die komplette Dokumentation der Klassen
des Content Miner-API. Mithilfe dieser Klassen können JSP-Seiten
mit Suchfunktionen implementiert werden. Die Javadoc befindet sich
im Verzeichnis {WCM-Installationsverzeichnis}\
documentation \javadoc\.
10
Livelink WCM Server
Allgemeine Hinweise
Der Inhalt dieses Handbuchs ist folgendermaßen gegliedert:

Kapitel 2 “Konzepte” erläutert die grundlegenden technischen
Konzepte von Lucene-Suchservern.

Kapitel 3 “Lucene-Suchserver verwalten” beschreibt die Konfiguration von Lucene-Suchservern über den Admin-Client und die
Konfigurationsdatei contentminer.xml.

Kapitel 4 “Index-System” beschreibt das Index-System von LuceneSuchservern sowie die Möglichkeiten, die Ihnen zur Beeinflussung
von Collections zur Verfügung stehen.

In Kapitel 5 “Query-System” wird das Query-System von LuceneSuchservern behandelt, wobei anhand von Beispielen die
Durchführung einer Suche beschrieben wird.

Anhang A “Abfragesyntax” beschreibt die Abfragesyntax von Lucene
und liefert entsprechende Anwendungsbeispiele.

Anhang B “Nicht unterstützte Funktionen des Content Miner-API”
enthält eine Übersicht über die Methoden des Content Miner-API,
die von Lucene-Suchservern nicht unterstützt werden.
11
Kapitel 1
1.3 Typographische Konventionen
Programmelemente u.Ä. werden im Text folgendermaßen hervorgehoben:
Element
Schriftart oder Symbol
Beispiele
Programmoberfläche
wie z.B. Menübefehle,
Fenster, Dialoge, Feldund Schaltflächenbezeichnungen
Menü → Eintrag
Datei → Anlegen
Pfade zu Verzeichnissen, Namen von
Dateien und Verzeichnissen
Laufwerk:\Verzeichnis\
Dateiname
D:\WCM\
admin.bat
Zitate aus Programmcode oder Konfigurationsdateien
Code-Zitate
<head>
<title>heading
</title>
</head>
Variablen, d. h.
Platzhalter für
bestimmte Elemente
{Variable}
{WCMInstallationsverzeichnis}
Wichtige Hinweise und Warnungen stehen in grauen Kästen. Diese
Informationen sollten Sie unbedingt lesen, um Fehler bei der Nutzung
und Verwaltung von WCM-Systemen sowie Datenverluste zu
vermeiden.
12
Livelink WCM Server
Allgemeine Hinweise
13
14
Livelink WCM Server
KAPITEL 2
Konzepte
2
Dieses Kapitel beschreibt die Konzepte von Suchservern in
Livelink WCM Server. Suchserver für die semantische und Volltextsuche
heißen Content Miner-Suchserver. Für die alleinige Volltextsuche können
Lucene-Suchserver in das WCM-System eingebunden werden. Im
Folgenden wird zunächst auf die grundlegende Funktionsweise von Suchservern mit ihren Hauptkomponenten eingegangen und anschließend auf
die gesamte Systemarchitektur.
2.1 Allgemeine Funktionsweise
Die Hauptaufgabe einer Suchmaschine besteht darin, eine große Anzahl
von Dokumenten unterschiedlicher Ausgangsformate schnell und intelligent suchbar zu machen. In der Regel wird diese Aufgabe wie folgt gelöst:
Zunächst wird ein Index für einen Dokumentensatz erstellt. Dabei handelt
es sich um eine Liste von Merkmalen, die innerhalb eines Dokumentensatzes für die Suche nach bestimmten Dokumenten herangezogen
werden kann. Anschließend können Suchanfragen an den erzeugten
Index gestellt und in Form von Trefferlisten beantwortet werden.
15
Kapitel 2
In Anlehnung an diese Vorgehensweise ist die Funktionalität von Suchservern in Livelink WCM Server auf folgende zwei Module aufgeteilt: das
Index-System und das Query-System.

Das Index-System erstellt und verwaltet einen Index für einen Dokumentensatz. Dabei fügt es diesem Dokumentensatz neue
Dokumente hinzu, löscht alte und aktualisiert geänderte Dokumente.
Der Index eines Dokumentensatzes wird als Collection bezeichnet.

Das Query-System nimmt Suchanfragen eines Benutzers an, verarbeitet diese und liefert eine entsprechende Trefferliste zurück. Die
Trefferliste spiegelt dabei den Zustand des Dokumentensatzes zum
Zeitpunkt der Indexierung wider.
Jeder Suchserver ist genau einem Content-Server zugeordnet. Einem
Content-Server können mehrere Suchserver zugeordnet sein. Außerdem
kann jeder Suchserver mehrere Collections verwalten.
Hinweis: Lucene-Suchserver sind direkt in den Content-Server integriert. Es gibt deshalb keine eigene Java-Prozesse.
Die folgende Abbildung veranschaulicht, wie die einzelnen Komponenten
zueinander in Beziehung stehen:
16
Livelink WCM Server
Konzepte
Content-Server
(Master/Proxy)
Suchserver n
Suchserver 2
Suchserver 1
Query-System
Collection
1-p
Index-System
Collection
1-m
Collection
1-n
Abb. 1 – Zuordnung von mehreren Suchservern zu einem Content-Server
Collections werden über den Admin-Client erzeugt. Auch das Löschen
von Collections und das Festlegen von Konfigurationseigenschaften
erfolgen über den Admin-Client (siehe dazu auch Kapitel 3 “Lucene-Suchserver verwalten”).
Collections werden in interne und externe Collections unterteilt: Eine
interne Collection wird aus einem Dokumentensatz gebildet, der über ein
WCM-System verwaltet wird. Eine externe Collection wird im Gegensatz
dazu aus einem Dokumentensatz gebildet, der durch ein beliebiges
externes System bereitgestellt wird.
17
Kapitel 2
2.2 Index-System
Die Erzeugung eines Index durch das Index-System ist aufgrund der
Verknüpfung des Suchservers mit dem Content-Server in den WCM-Bearbeitungsprozess integriert. Dabei übernimmt der Content-Server die Koordination der zu indexierenden Dokumente. In diesem Zusammenhang
stehen zwei unterschiedliche Mechanismen zur Verfügung.

Synchronisierung des Index mit dem aktuellen Dokumentensatz
In dieser Konfiguration wird sowohl die Datenpflege als auch die
Indexerstellung vom WCM-System übernommen bzw. initiiert. Dabei
werden interne Collections bearbeitet. Ereignisse wie das Erstellen
und Löschen von Dokumenten sowie Staging-basierte Ereignisse
wie das Zurückgeben, Vorlegen und Freigeben von Dokumenten
werden ebenfalls verarbeitet. Dabei ist der Index zu jedem Zeitpunkt
mit dem aktuellen Dokumentensatz synchronisiert.

Bei dieser Konfiguration wird der Dokumentensatz unabhängig vom
WCM-System gepflegt und manuell bzw. über externe Systeme
bereitgestellt. Die Indexerstellung wird mithilfe der KommandozeilenTools initiiert, wobei diese die entsprechenden Befehle an das WCMSystem bzw. den Suchserver geben. Die Tools sind als Java-Applikationen implementiert, die z.B. über die Eingabeaufforderung
gestartet werden können. Über Kommandozeilen-Tools kann sowohl
auf interne als auch auf externe Collections zugegriffen werden;
schreibende Zugriffe sind jedoch nur für externe Collections sinnvoll.
Die folgende Grafik veranschaulicht das Zusammenspiel von IndexSystem und WCM-System und stellt den Datenfluss heraus:
18
Livelink WCM Server
Konzepte
KommandozeilenTools
Dokumentensatz 1
Agent "ContentMinerBenachrichtigung"
WCM-System
pflegen
indexieren
IndexSystem
Manuelle
Datenpflege
pflegen
indexieren
Dokumentensatz 2
Datenfluss
Index-Kommando
Collection 1-n
(intern)
Collection 1-m
(extern)
Abb. 2 – Beteiligte Komponenten beim Erzeugen eines Index
Das WCM-System übernimmt im dargestellten Szenario die Datenpflege
des Dokumentensatzes 1, wobei die Repräsentationen der Dokumente im
Dateisystem angelegt werden. Dabei initiiert das WCM-System auch die
Indexerstellung mithilfe des Agenten “ContentMiner-Benachrichtigung”,
der das Index-System ansteuert. Dieses greift über das Dateisystem auf
den Dokumentensatz zu.
Der Dokumentensatz 2 wird unabhängig vom WCM-System gepflegt und
manuell oder über externe Systeme zur Verfügung gestellt. Die Indexerstellung wird in diesem Fall mithilfe der Kommandozeilen-Tools initiiert,
die das WCM-System ansprechen, woraufhin der Agent “ContentMinerBenachrichtigung” den entsprechenden Befehl an das Index-System
weiterleitet.
19
Kapitel 2
2.3 Query-System
Das Query-System stellt einen Mechanismus zur Verfügung, mit dem
Suchanfragen verarbeitet und entsprechende Trefferlisten erzeugt werden
können. Die erforderliche agierende Komponente ist dabei die JSP-Seite
bzw. die JSP-Engine, die die Anfragen an das Query-System stellt.
Die folgende Grafik veranschaulicht das Zusammenspiel der einzelnen
Komponenten:
Collection 1-n
Webserver
JSP-Engine
lesen
Servlet
QuerySystem
VipContentMinerBean
JSP-Seite
Trefferliste
Anfrage
HTTP-Request
Datenfluss
Webbrowser
Query-Kommando
Abb. 3 – Beteiligte Komponenten beim Verarbeiten einer Suchanfrage
Der Webbrowser erzeugt ausgehend von einem Suchformular einen
HTTP-Request. In dem Suchformular sind die Parameter der Anfrage
spezifiziert, wobei beispielsweise eine Collection ausgewählt und eine
Suchanfrage eingegeben werden kann. Der HTTP-Request fordert vom
20
Livelink WCM Server
Konzepte
Webserver eine JSP-Seite an, die im Formular spezifiziert ist und die
Funktionalität zur Ausführung der Anfrage aufruft. Das Servlet, das aus
der JSP-Seite generiert wird, bzw. das VipContentMinerBean stellt die
Anfrage an das Query-System, das anhand der Collection eine entsprechende Trefferliste erzeugt. Diese steht anschließend zur Verarbeitung
durch die JSP-Engine zur Verfügung.
Die JSP-Seite kann individuell angepasst werden, sodass eine vollständige Kontrolle über die Aspekte der Suche möglich ist. Die Suchserver
von Livelink WCM Server stellen alle benötigten Kontrollinstrumente zur
Verfügung – bestehend aus dem VipContentMinerBean und zahlreichen
Hilfsklassen – die die Kommunikation mit dem Query-System übernehmen und die Suchergebnisse bereitstellen. Das
VipContentMinerBean wird zu diesem Zweck mit den Eingaben aus dem
HTTP-Request parametrisiert, übersetzt die Parameterwerte in die Abfragesprache des Query-Systems, versendet die Anfrage und empfängt die
Trefferliste.
Hinweis: Das VipContentMinerBean kann nicht außerhalb des WCMSystems benutzt werden. Voraussetzung ist stets ein Master- oder
Proxy-Content-Server.
2.4 Systemarchitektur
Im Folgenden werden die Systemarchitektur sowie der Funktionsablauf
innerhalb eines Szenarios mit integriertem Suchserver erläutert. Zu
diesem Zweck werden zunächst grundlegende Begrifflichkeiten im
Zusammenhang mit einem WCM-System geklärt. Ein Beispielszenario
wird im Anschluss daran beschrieben.
21
Kapitel 2
Grundlagen
Die WCM-Server werden in die zwei Hauptkategorien Master und Proxy
unterteilt. In jedem WCM-System gibt es einen Master-Administrationsserver und einen bzw. mehrere Master-Content-Server.
Der Master-Administrationsserver steuert die Benutzerverwaltung und
übernimmt Konfiguration, System- und Lizenzverwaltung. Der Zugang
zum Administrationsserver erfolgt über den Admin-Client.
Der Master-Content-Server verwaltet eine oder mehrere Websites,
wobei eine Website immer genau einem Master-Content-Server zugeordnet ist. Nur an einem Master-Content-Server können Änderungen an
Inhalt und Status von WCM-Objekten durchgeführt werden. Auf dem
Master-Content-Server stehen immer alle Datenhaltungssichten (Edit, QS
und Produktion) zur Verfügung.
Zusätzlich zum Master-Content-Server können Sie in einem WCMSystem Proxy-Content-Server einrichten, auf denen die Daten der
Website(s) mithilfe entsprechender Deploymentsysteme ebenfalls
verfügbar gemacht werden. Im Unterschied zu einem Master-ContentServer haben Proxy-Content-Server jedoch nur lesenden Zugriff auf die
Daten. Sollen Website-Daten über einen Proxy-Content-Server bearbeitet
werden, wendet sich der Proxy-Content-Server an den Master-ContentServer. Dieser sperrt das Objekt für weitere schreibende Zugriffe und
speichert nach Abschluss der Bearbeitung die geänderten Objekte in der
Datenhaltung. Anschließend informiert der Master-Content-Server alle
angeschlossenen Proxy-Content-Server der Website darüber, dass sich
das WCM-Objekt geändert hat. Auf diese Weise bleiben Ihre WebsiteInhalte konsistent.
Für die Verteilung der Seiten im WCM-System sind die so genannten
Deploymentsysteme zuständig. Das Deployment benachrichtigt den
Agenten “ContentMiner-Benachrichtigung” über Änderungen an den
WCM-Objekten.
22
Livelink WCM Server
Konzepte
Aufgrund der flexiblen Systemarchitektur mit Master- und Proxy-Servern
gibt es für den Aufbau eines WCM-Systems zahlreiche Möglichkeiten. Da
Sie jederzeit weitere Server und Deploymentsysteme hinzufügen können,
bietet Livelink WCM Server außerdem die Möglichkeit, ein installiertes
System auszubauen, wenn sich die Anforderungen Ihres Unternehmens
ändern. Weitere Informationen finden Sie im Livelink WCM Server-Administratorhandbuch und -Installationshandbuch.
Integration von Suchservern
Im Folgenden wird die Integration von Suchservern in ein WCM-System
mit dem zugrunde liegenden Datenfluss anhand eines MinimalsystemSzenarios beschrieben.
Das WCM-System besteht aus einem Master-Admin-Server und einem
Master-Content-Server. Der Master-Content-Server wird im Kontext einer
JSP-Engine bzw. als Webanwendung in einem Application-Server ausgeführt.
23
Kapitel 2
Master-Admin-Server
1
JSP-Engine
Deploymentsysteme 1-p
Master-ContentServer
DS
4
1
2 p
Suchserver
3
Index-System
Agent "ContentMinerBenachrichtigung"
5
Query-System
Content Miner-Klassen
2
1
2
Collection 1-n
(intern)
n
1
2
m
Collection 1-m
(extern)
Abb. 4 – Integration von Suchservern in ein WCM-System
Über den Master-Admin-Server können Collections angelegt und auch
gelöscht werden c. Diese Vorgänge erfolgen synchron. Die agierende
Komponente ist dabei der Agent “ContentMiner-Benachrichtigung”, der
die entsprechenden Befehle zum Anlegen bzw. Löschen der Collections
an das Index-System weiterleitet e. Mithilfe der KommandozeilenTools d können Indexierungsaktionen für externe Collections durchgeführt werden. Dies erfolgt ebenfalls synchron, und auch in diesem Fall
übernimmt der Agent “ContentMiner-Benachrichtigung” eine zentrale
Funktion, da er die Anweisungen entsprechend weiterleitet.
24
Livelink WCM Server
Konzepte
Eine interne Collection basiert auf einem Deploymentsystem, wobei jede
interne Collection immer genau einem Deploymentsystem zugeordnet ist.
Auf diese Weise ist eine interne Collection auch immer indirekt einer
Website zugeordnet. Das Deploymentsystem muss dabei auf demjenigen
Content-Server eingerichtet sein, dem der entsprechende Suchserver
zugeordnet ist. Interne Collections können nur auf Basis eines Standardoder eines Suchmaschinen-Deploymentsystems angelegt werden.
Das Erstellen und Löschen von WCM-verwalteten Dokumenten erfolgt
über den Master-Content-Server, der die entsprechenden Informationen
an das jeweilige Deploymentsystem weiterleitet. Dabei wird der Index
bzw. die interne Collection zu jedem Zeitpunkt mit dem aktuellen Dokumentensatz synchronisiert f, d.h., der durch das WCM-System verwaltete Dokumentensatz wird mit dem durch den Suchserver indexierten
Dokumentensatz abgeglichen. Beim Erstellen und Löschen der Dokumente feuert das Deploymentsystem jeweils ein Event, auf das sich der
Agent “ContentMiner-Benachrichtigung” registriert. Die angenommenen
Events werden in eine “Warteschlange” gestellt, die anschließend asynchron abgearbeitet wird.
Außerdem kann das Synchronisieren einer internen Collection über den
Admin-Client manuell ausgelöst werden (siehe dazu den Abschnitt
“Interne Collection synchronisieren” auf Seite 40). Dies ist beispielsweise
erforderlich, wenn die Gefahr besteht, dass die Dokumentensätze z.B.
infolge längerer Netzwerkstörungen nicht mehr übereinstimmen. Beim
Synchronisieren wird der Index überschrieben.
Der Master-Content-Server läuft im Kontext einer JSP-Engine. Wenn
Suchanfragen erfolgen, werden auf entsprechenden JSP-Seiten
Content Miner-Klassen benutzt, um auf das Query-System eines Suchservers zuzugreifen g. Die Content Miner-Klassen stellen die jeweiligen
Funktionen zur Verfügung, damit auf den indexierten Collections Suchanfragen durchgeführt werden können.
25
26
Livelink WCM Server
KAPITEL 3
3
Dieses Kapitel beschreibt, wie Sie Lucene-Suchserver verwalten. Die
gesamte Konfiguration Ihres WCM-Systems erfolgt über den AdminClient. An dieser zentralen Stelle nehmen Sie also auch die Administration
und Konfiguration von Suchservern vor.
Sie verwalten Lucene-Suchserver im Admin-Client in den zwei Ansichten
Konfiguration und Systemverwaltung. Welche Optionen Ihnen in der
jeweiligen Ansicht zur Verwaltung von Lucene-Suchservern zur Verfügung
stehen, erfahren Sie in den folgenden Abschnitten.
Hinweis: Die Verwaltung der übrigen Elemente und die Bedienung des
Admin-Clients werden ausführlich im Livelink WCM Server-Administratorhandbuch beschrieben.
Am Ende dieses Kapitels erhalten Sie außerdem Informationen zur Konfigurationsdatei contentminer.xml und erfahren, wie Sie Analyzer und
Parser in einen Lucene-Suchserver einbinden.
27
Kapitel 3
3.1 Lucene-Suchserver konfigurieren
Um die Konfiguration zu öffnen, starten Sie den Admin-Client und wählen
das Register
.
In einer baumartigen Ansicht sehen Sie die Elemente, die Sie verwalten
können.
Abb. 5 – Die Elemente der Konfiguration
Wenn Sie das Baumelement Suchserver öffnen, werden Ihnen alle
verfügbaren Content Miner- und Lucene-Suchserver angezeigt – sowohl
im Baum links als auch in einer Liste im rechten Fensterbereich. Die hier
angezeigten Suchserver haben Sie bei der Installation des WCM-Systems
eingerichtet.
28
Livelink WCM Server
Abb. 6 – Übersicht über die installierten Suchserver in der Ansicht Konfiguration
Folgende Funktionen stehen Ihnen in dieser Ansicht für Lucene-Suchserver zur Verfügung:

Einstellungen der installierten Suchserver einsehen (siehe folgenden
Abschnitt)

Collections verwalten (siehe Abschnitt “Collections verwalten” auf
Seite 30)
Einstellungen der installierten Suchserver
Um die Einstellungen eines Suchservers einzusehen, markieren Sie den
entsprechenden Suchserver über Konfiguration → Suchserver →
{Suchservername}.
Im rechten Fensterbereich werden die Einstellungen der Suchserver
angezeigt. Eine genaue Erläuterung der einzelnen Parameter finden Sie
in der Online-Hilfe des Admin-Clients.
29
Kapitel 3
Abb. 7 – Einstellungen eines Lucene-Suchservers
Hinweis: Beachten Sie, dass Sie die Einstellungen der installierten
Suchserver nicht über den Admin-Client verändern können. Sie können
hier auch keine Suchserver hinzufügen oder entfernen. Dies erfolgt
mithilfe des Installationsprogramms. Genaue Informationen dazu finden
Sie im Livelink WCM Server-Installationshandbuch.
Collections verwalten
Nach der Installation verfügt ein Suchserver noch nicht über Collections.
Diese legen Sie über den Admin-Client an. Sie können beliebig viele
interne und externe Collections verwalten.
Eine interne Collection wird aus einem Dokumentensatz gebildet, der über
das WCM-System verwaltet wird. Eine externe Collection wird aus einem
Dokumentensatz gebildet, der durch ein beliebiges externes System
bereitgestellt wird.
Hinweis: Um Collections anlegen und mit diesen arbeiten zu können,
muss auf dem Content-Server, dem der Lucene-Suchserver zugeordnet
ist, der Agent “ContentMiner-Benachrichtigung” laufen.
30
Livelink WCM Server
Folgende Funktionen stehen Ihnen für Collections zur Verfügung:

interne Collection anlegen (siehe folgenden Abschnitt)

externe Collection anlegen (siehe Abschnitt “Neue externe Collection
anlegen” auf Seite 35)

Einstellungen einer Collection einsehen (siehe Abschnitt “Einstellungen einer Collection” auf Seite 36)

Collection löschen (siehe Abschnitt “Collection löschen” auf Seite 38)
Neue interne Collection anlegen
Hinweise:
Deploymentsysteme bilden die Voraussetzung für das Anlegen interner
Collections. Für die Indexierung der Metadaten von WCM-Objekten gibt
es speziell die so genannten Suchmaschinen-Deploymentsysteme.
Richten Sie deshalb zunächst ein Suchmaschinen-Deploymentsystem
ein, wenn Sie die Metadaten in die Indexierung einbeziehen möchten.
Informationen dazu finden Sie im Livelink WCM ServerAdministratorhandbuch.
Interne Collections können nur auf Basis eines Standard- oder eines
Suchmaschinen-Deploymentsystems angelegt werden.
So fügen Sie einem Suchserver eine neue interne Collection hinzu:
1. Wählen Sie Konfiguration → Suchserver.
2. Markieren Sie den gewünschten Suchserver.
3. Wählen Sie Neue interne Collection aus dem Kontextmenü, oder
klicken Sie auf das entsprechende Symbol.
Symbol zum Anlegen einer neuen internen Collection
31
Kapitel 3
Der Assistent zum Anlegen einer neuen internen Collection wird
gestartet.
4. Folgen Sie den Anweisungen des Assistenten.
Schritt 1 – Name und Deploymentsystem festlegen
Abb. 8 – Neue interne Collection anlegen

Name: Geben Sie hier einen Namen für die neue interne Collection
an. Dieser Name ist frei wählbar, muss jedoch innerhalb des WCMSystems eindeutig sein.

Deploymentsystem: Wählen Sie hier das Deploymentsystem aus,
dessen generierte Objekte indexiert werden sollen. Zur Auswahl
stehen die Deploymentsysteme, die auf dem Content-Server eingerichtet sind, dem dieser Suchserver zugeordnet ist.
Wenn Sie zusätzlich die Metadaten Ihrer WCM-Objekte indexieren
möchten, wählen Sie aus der Liste das entsprechende Suchmaschinen-Deploymentsystem. Beim Einrichten dieses
Deploymentsystems wurden die zu indexierenden Metadaten bereits
festgelegt.
32
Livelink WCM Server
Um die Eingaben zu bestätigen, klicken Sie auf die Schaltfläche Weiter.
Schritt 2 – Wurzelobjekt und Objekttypen festlegen
Es ist möglich, nur Teilbereiche einer Website zu indexieren. Im folgenden
Dialog können Sie optional eine OID angeben. Diese OID wird dann als
Wurzelobjekt interpretiert, ab dem die Indexierung erfolgen soll.
Außerdem wählen Sie hier die Objekttypen aus, deren zugehörige generierte Objekte Sie indexieren möchten. Eine Reihe von typischerweise
verwendeten Objekttypen ist in der rechten Spalte bereits ausgewählt.
Abb. 9 – Wurzelobjekt und Objekttypen festlegen
33
Kapitel 3

Wurzelobjekt: Um die Indexierung auf einen Teilbereich der Website
zu beschränken, geben Sie hier die OID an, ab der die Indexierung
erfolgen soll. Wenn das Feld leer bleibt, wird die gesamte Website
indexiert.

Verfügbare Objekttypen: Hier werden Ihnen alle verfügbaren Objekttypen angezeigt.

Ausgewählte Objekttypen: Hier werden Ihnen die bereits ausgewählten Objekttypen angezeigt.
Um weitere Objekttypen auszuwählen bzw. um bereits ausgewählte
Objekttypen wieder aus der Liste zu entfernen, markieren Sie den
entsprechenden Objekttyp und übertragen ihn mit
bzw.
oder per
Doppelklick in die entsprechende Spalte.
Um die interne Collection anzulegen, klicken Sie auf die Schaltfläche
Fertig.
Die neue Collection erscheint in der baumartigen Ansicht des AdminClients unterhalb des Knotens des Lucene-Suchservers. Eine interne
Collection ist im Baum durch einen rosafarbenen Balken gekennzeichnet.
Abb. 10 – Darstellung einer internen Collection in der baumartigen Ansicht
Hinweis: Bevor Sie die neu angelegte Collection für Suchanfragen
nutzen können, muss die Collection synchronisiert werden (siehe
Abschnitt “Interne Collection synchronisieren” auf Seite 40).
34
Livelink WCM Server
Neue externe Collection anlegen
So fügen Sie einem Suchserver eine neue externe Collection hinzu:
1. Wählen Sie Konfiguration → Suchserver
2. Markieren Sie den gewünschten Suchserver.
3. Wählen Sie Neue externe Collection aus dem Kontextmenü, oder
Symbol zum Anlegen einer neuen externen Collection
Sie gelangen zu folgendem Dialog.
Abb. 11 – Neue externe Collection anlegen
4. Geben Sie im Feld Name einen Namen für die neue externe Collection an. Dieser Name ist frei wählbar, muss jedoch innerhalb des
WCM-Systems eindeutig sein.
5. Klicken Sie auf die Schaltfläche Fertig.
35
Kapitel 3
Die neue Collection erscheint in der baumartigen Ansicht des AdminClients unterhalb des Knotens des Lucene-Suchservers. Eine
externe Collection ist im Baum durch einen blauen Balken
gekennzeichnet.
Abb. 12 – Darstellung einer externen Collection in der baumartigen Ansicht
Hinweis: Bevor Sie die neu angelegte Collection für Suchanfragen
nutzen können, müssen der Collection mithilfe des KommandozeilenTools AddDocument bzw. AddDirectory Dokumente hinzugefügt
werden (siehe Abschnitte “AddDocument” auf Seite 64 und
“AddDirectory” auf Seite 60).
Einstellungen einer Collection
Um die Einstellungen einer Collection einzusehen oder zu bearbeiten,
gehen Sie folgendermaßen vor.
1. Wählen Sie Konfiguration → Suchserver → {Suchservername}.
2. Markieren Sie die gewünschte Collection.
Im rechten Fensterbereich werden die Register mit den Einstellungen angezeigt, die Sie beim Anlegen der Collection
vorgenommen haben. Die Art und Anzahl der angezeigten Register
hängt davon ab, ob es sich um eine interne oder externe Collection
handelt.
36
Livelink WCM Server
Abb. 13 – Einstellungen einer Collection

Die Angaben auf dem Register Name und Deploymentsystem
(interne Collection) bzw. Name (externe Collection) können Sie
nicht ändern.

Auf dem Register Wurzelobjekt und Objekttypen (interne Collection) geben Sie die OID eines Wurzelobjekts an, ab dem die
Indexierung erfolgen soll. Außerdem wählen Sie die Objekttypen
aus, deren zugehörige generierte Objekte Sie indexieren
möchten.
Eine genaue Erläuterung der einzelnen Parameter finden Sie in den
Abschnitten “Neue interne Collection anlegen” auf Seite 31 und
“Neue externe Collection anlegen” auf Seite 35 sowie in der OnlineHilfe des Admin-Clients.
3. Nehmen Sie die gewünschten Änderungen vor.
4. Klicken Sie auf die Schaltfläche Übernehmen.
Hinweis: Nach Änderungen in der Konfiguration muss eine interne Collection synchronisiert werden, um sie der neuen Konfiguration
anzupassen (siehe Abschnitt “Interne Collection synchronisieren” auf
Seite 40.)
37
Kapitel 3
Collection löschen
So löschen Sie eine Collection:
1. Wählen Sie Konfiguration → Suchserver
→ {Suchservername}.
2. Markieren Sie die zu löschende Collection.
3. Wählen Sie Collection löschen aus dem Kontextmenü, oder klicken
Sie auf das entsprechende Symbol.
Symbol zum Löschen einer Collection
4. Bestätigen Sie die folgende Sicherheitsabfrage mit Ja.
3.2 Lucene-Suchserver in der
Systemverwaltung
Um die Systemverwaltung zu öffnen, starten Sie den Admin-Client und
wählen das Register
am unteren Fensterrand.
In einer baumartigen Ansicht sehen Sie die Elemente, die Sie hier
verwalten können.
Abb. 14 – Die Elemente der Systemverwaltung
38
Livelink WCM Server
Wenn Sie das Baumelement Suchserver öffnen, werden Ihnen alle
verfügbaren Suchserver angezeigt – sowohl im Baum links als auch in
einer Liste im rechten Fensterbereich. Die hier dargestellten Suchserver
haben Sie bei der Installation des WCM-Systems eingerichtet.
Abb. 15 – Übersicht über die installierten Suchserver in der Systemverwaltung
In der Systemverwaltung können Sie den Zustand von Collections beeinflussen (siehe folgenden Abschnitt).
Collections beeinflussen
Die Ansicht Systemverwaltung bietet Ihnen verschiedene Möglichkeiten,
die angelegten internen und externen Collections zu beeinflussen.
Folgende Funktionen stehen Ihnen zur Verfügung:

Synchronisieren einer internen Collection (siehe folgenden
Abschnitt)

Komprimieren einer Collection (siehe Abschnitt “Collection komprimieren” auf Seite 41)
39
Kapitel 3
Interne Collection synchronisieren
Eine interne Collection wird aus einem Dokumentensatz gebildet, der
durch ein WCM-System verwaltet wird. Der Vorgang des Synchronisierens bewirkt, dass der WCM-verwaltete Dokumentensatz mit dem durch
den Lucene-Suchserver indexierten Dokumentensatz abgeglichen wird.
Änderungen, die Sie an Ihren WCM-verwalteten Dokumentensätzen
vornehmen, wie z. B. das Hinzufügen oder Löschen von Dokumenten,
bewirken eine automatische Synchronisierung der entsprechenden Collections (siehe Abschnitt “Automatisches Synchronisieren” auf Seite 52).
Das (manuelle) Synchronisieren ist dagegen erforderlich, wenn Sie Änderungen in der Konfiguration der internen Collection vorgenommen haben
oder die Dokumentensätze durch längere Netzwerkstörungen nicht mehr
übereinstimmen. Beim Synchronisieren wird der Index überschrieben.
So synchronisieren Sie eine interne Collection:
1. Wählen Sie Systemverwaltung → Suchserver → {Suchservername}.
3. Wählen Sie Collection synchronisieren aus dem Kontextmenü, oder
Symbol zum Synchronisieren einer internen Collection
4. Bestätigen Sie die folgenden Sicherheitsabfragen mit Ja und OK.
Hinweis: Der Synchronisierungsprozess kann längere Zeit in Anspruch
nehmen. Er läuft auf dem Lucene-Suchserver als Hintergrundprozess
ab. Die Arbeit im Admin-Client kann währenddessen ohne Einschränkungen fortgesetzt werden.
40
Livelink WCM Server
In den Protokoll- und Fehlerdateien des Content-Servers, dem der Suchserver zugeordnet ist, werden sämtliche Aktionen sowie eventuell auftretende Fehler gespeichert.
Hinweis: Sobald im Bericht “ContentMinerAgent:{Servername}” der
Eintrag current queue has 0 requests erscheint, ist der Prozess der
Synchronisierung abgeschlossen. Diesen Bericht öffnen Sie über
Systemverwaltung → Laufende Server → {Servername} → Berichte.
Weitere Informationen zu Server-Berichten finden Sie im
Livelink WCM Server-Administratorhandbuch.
Collection komprimieren
Verschiedene Aktionen wie z.B. das Hinzufügen oder Löschen von Dokumenten führen dazu, dass der Index nicht mehr aktuell ist bzw. ungültig
wird. Beispielsweise werden die Indexeinträge gelöschter Dokumente als
“gelöscht” markiert und treten im Index auch nicht mehr auf. Dennoch
werden diese Einträge in der Indexdatei weiterhin als “gelöscht” mitgeführt.
Das Komprimieren einer Collection dient dazu, diesen veralteten Zustand
zu aktualisieren und damit die Größe des Index auf die erforderliche Minimalgröße zu reduzieren. Zur Optimierung des Index sollten Sie eine Collection in regelmäßigen Abständen komprimieren.
Sie können sowohl externe als auch interne Collections komprimieren. So
komprimieren Sie eine Collection:
1. Wählen Sie Systemverwaltung → Suchserver → {Suchservername}.
41
Kapitel 3
3. Wählen Sie Collection komprimieren aus dem Kontextmenü, oder
Symbol zum Komprimieren einer internen Collection
Symbol zum Komprimieren einer externen Collection
4. Bestätigen Sie die folgende Sicherheitsabfrage mit Ja.
Lucene-Suchserver starten und stoppen
Um Collections anlegen und mit diesen arbeiten zu können, muss der
Suchserver, der die entsprechenden Collections verwalten soll, gestartet
sein. Lucene-Suchserver können nur auf dem Hostrechner installiert
werden, auf dem der zugeordnete Content-Server installiert ist. Sie
werden immer automatisch zusammen mit dem Server gestartet und
gestoppt.
3.3 Die Datei conte nt miner.xml
In der Datei {WCM-Installationsverzeichnis}\config\comi\
contentminer.xml werden die Einstellungen, die Sie während der
Installation für Suchserver vornehmen, gespeichert. Sie können mithilfe
dieser Datei außerdem so genannte Analyzer und Parser in den Suchserver einbinden und den Zugriff mehrerer Content-Server auf eine Collection konfigurieren.
Analyzer sind Java-Klassen, die den eigentlichen Content eines Dokuments analysieren. Sie steuern, wie der Content eines Dokuments
während der Indexierung in Begriffe (Terms) aufgeteilt wird. Analyzer
können außerdem bestimmte Operationen ausführen, etwa die Umwand-
42
Livelink WCM Server
lung aller Begriffe in Kleinschreibung oder das Herausfiltern von Wörtern,
die für die Indexierung nicht berücksichtigt werden sollen, der so
genannten Stop-Words (z.B. Artikel und Konjunktionen).
Parser sind Java-Klassen, die für die Indexierung den eigentlichen
Content eines Dokuments extrahieren. Sie sind abhängig vom Dateityp.
Für HTML-Dateien wird deshalb beispielsweise ein anderer Parser benötigt als für Word-Dateien.
Hinweis: Wenn Sie dieselbe Parserklasse für mehrere Dateitypen
verwenden, z. B. für JSP- und HTML-Dateien, tragen Sie die entsprechenden Endungen im Element <extension> der Parserklasse ein
(siehe unten). Für jede Parserklasse darf es nur ein <parser>-Element
geben.
Beispiel (contentminer.xml)
<ContentMiner>
<search-server name="Lucene-Suchserver">
<search-product>Lucene</search-product>
<reload-interval>300000</reload-interval>
<vip-server-name>Master-Content</vip-server-name>
<index-location>
<server name="Master-Content">D:\wcm\contentminer
</server>
</index-location>
<parser name="HTMLandJSPParser">
<class>de.gauss.vip.contentminer.product.lucene.parser.
HTMLParser</class>
<extensions>htm.HTM.html.HTML.jsp.JSP</extensions>
</parser>
<analyzer>
<class>de.gauss.vip.contentminer.product.lucene.analyzer.
StandardAnalyzer</class>
<stop-words>und oder der die das</stop-words>
</analyzer>
</search-server>
</ContentMiner>
43
Kapitel 3
Tabelle 1 – Einträge in der Datei contentminer.xml
Eintrag
Beschreibung
Während
Installation
<search-server
name>
Eindeutiger Name des Suchservers
<searchproduct>
Produktname der Suchmaschine
(= Lucene)
<reloadinterval>
Zeitspanne in Millisekunden, nach der
alle Collections für den lesenden Zugriff
neu geladen werden
<vip-servername>
Name des Content-Servers, dem der
Suchserver zugeordnet ist
<indexlocation>
Pfad zu dem Verzeichnis im Dateisystem, in dem der Index gespeichert ist
Wenn mehrere Content-Server dieselbe
Collection durchsuchen sollen, muss
dieser Pfad für die entsprechenden
Content-Server zugreifbar sein. Die Pfadnamen können dabei für Server, die auf
verschiedenen Rechnern installiert sind,
unterschiedlich sein.
Um die Pfade für die Server zu konfigurieren, fügen Sie dem Element <indexlocation> Unterelemente vom Typ
<server> zu. In dem Attribut <name>
wird der Name des Content-Servers
angegeben, das Element selbst enthält
den Pfad, den der Server für den Zugriff
auf das Verzeichnis mit dem Index
verwenden soll.
44
Livelink WCM Server
Eintrag
Beschreibung
Während
Installation
Beispiel:
<index-location>
<server name="Master">
D:\wcm\contentminer</server>
<server name="Proxy">
S:\wcm\contentminer</server>
</index-location>
<parser name>
Eindeutiger Name des Parsers (Komponente, die den Content extrahiert)
Siehe Abschnitt “Parser für LuceneSuchserver” auf Seite 48
<class>
Eine zu instanziierende Java-Klasse, die
das Interface de.gauss.vip.
contentminer.product.lucene.
parser.ContentParser implementiert
<extensions>
Durch Punkte getrennte Liste von
Dateiendungen. Der Parser wird für
Dateien mit diesen Endungen zum
Einlesen des Content verwendet.
<analyzer>
Analyse-Komponente zur Indexierung
Siehe folgenden Abschnitt
<class>
Eine zu instanziierende Java-Klasse, die
das Interface de.gauss.vip.
contentminer.product.lucene.
analyzer.AnalyzerHelper
implementiert
45
Kapitel 3
Eintrag
Beschreibung
Während
Installation
<stop-words>
Durch Leerzeichen getrennte Liste von
Wörtern, die bei der Indexierung nicht
berücksichtigt werden sollen (StopWords)
Dieser Parameter ist optional. Ist der
Parameter nicht gesetzt, wird der Standard-Konstruktor der Klasse verwendet.
Mögliche Zustände der Liste: nicht
definiert, leer, explizit definiert
Analyzer für Lucene-Suchserver
Mitgelieferte Analyzer
Folgende Analyzer werden mitgeliefert (Package
de.gauss.vip.contentminer.product.lucene.analyzer):

StandardAnalyzer (Wenn der Eintrag <analyzer> in der Datei
contentminer.xml nicht gesetzt ist, wird standardmäßig dieser
Analyzer verwendet.)

SimpleAnalyzer (unterstützt keine Stop-Words)

GermanAnalyzer

StopAnalyzer

WhitespaceAnalyzer (unterstützt keine Stop-Words)
46
Livelink WCM Server
Eigene Analyzer integrieren
So integrieren Sie eigene Analyzer in einen Lucene-Suchserver:
1. Erstellen Sie eine Klasse, die das Interface AnalyzerHelper
implementiert.
Nachfolgend finden Sie ein Beispiel für die Implementation. In
diesem Beispiel wird der Standard-Analyzer von Lucene gewrapped,
damit er in die Datei contentminer.xml eingebunden werden kann.
Den Standard-Analyzer finden Sie in der Datei {WCMInstallationsverzeichnis}\lib\lucene-1.4-rc3.jar.
package de.gauss.vip.contentminer.product.lucene.analyzer;
import org.apache.lucene.analysis.Analyzer;
/** Wraps the Lucene Standard Analyzer. */
public class StandardAnalyzer implements AnalyzerHelper
{
/** Lucene Stardard Analyzer */
private org.apache.lucene.analysis.standard.StandardAnalyzer
analyzerM = null;
/** Standard constructor */
public StandardAnalyzer()
{
}
/**
* Gets the internal analyzer.
*
* @return the internal analyzer.
*/
public Analyzer getAnalyzer()
{
if(analyzerM == null)
analyzerM = new org.apache.lucene.analysis.standard.
StandardAnalyzer();
return analyzerM;
}
47
Kapitel 3
/**
* Sets the stop words that should be used.
*
* @param stopwords the stop words that should be used.
*/
public void setStopWords(String[] stopwords)
{
analyzerM = new org.apache.lucene.analysis.standard.
StandardAnalyzer(stopwords);
}
}
2. Tragen Sie den Namen der in Schritt 1 erstellten Klasse in der Datei
contentminer.xml im Element <class> ein (siehe Tabelle 1
“Einträge in der Datei contentminer.xml” auf Seite 44).
Parser für Lucene-Suchserver
Mitgelieferte Parser
Nach der Installation eines Lucene-Suchservers ist der folgende HTMLParser konfiguriert:
de.gauss.vip.contentminer.product.lucene.parser.HTMLParser
Hinweis: Die Datei {WCM-Installationsverzeichnis}\examples\
luceneFilter*.zip enthält zusätzliche Parser. Diese dienen lediglich
als Beispiele und sind kein Produktbestandteil.
Eigene Parser integrieren
So integrieren Sie eigene Parser in einen Lucene-Suchserver:
1. Erstellen Sie eine Klasse, die das Interface ContentParser implementiert. Beispiele für die Implementierung enthält die Datei
luceneFilter*.zip.
48
Livelink WCM Server
2. Tragen Sie den Namen der in Schritt 1 erstellten Klasse in der Datei
contentminer.xml im Element <class> ein (siehe Tabelle 1
“Einträge in der Datei contentminer.xml” auf Seite 44).
49
50
Livelink WCM Server
KAPITEL 4
Index-System
4
Dieses Kapitel behandelt die Möglichkeiten, die einem Benutzer zur
Beeinflussung von Collections zur Verfügung stehen. Außerdem erhalten
Sie Informationen zur Anzahl der File-Handles, die eine Collection benötigt.
Hinweise:
Kapitel 2 “Konzepte” erläutert die grundlegende Funktionsweise des
Index-Systems sowie seine Integration in Lucene.
Die Funktionen zum Anlegen und Löschen von Collections sowie zum
Konfigurieren ihrer Eigenschaften sind in Kapitel 3 “Lucene-Suchserver
verwalten” beschrieben.
4.1 Synchronisieren
Beim Synchronisieren wird der aktuelle Zustand der Objekte eines
Deploymentsystems mit dem Inhalt der zugeordneten internen Collection
synchronisiert, d.h., der durch das WCM-System verwaltete Dokumentensatz wird mit dem indexierten Dokumentensatz abgeglichen. Auf diese
Weise ist die Konsistenz der Datenbestände gewährleistet.
51
Kapitel 4
Automatisches Synchronisieren
Aktionen im Deploymentsystem, die die Generierung oder Neugenerierung von Seiten bzw. ihrer Repräsentation im Dateisystem hervorrufen,
müssen bewirken, dass die betreffenden Dokumente zur entsprechenden
Collection hinzugefügt werden. Aktionen, die das Löschen von Seiten
bewirken, müssen dazu führen, dass die entsprechenden Dokumente aus
der Collection entfernt werden. Diese Aufgaben werden durch den
Agenten “ContentMiner-Benachrichtigung” übernommen. Dieser registriert sämtliche relevanten Aktionen und führt eine entsprechende Folgeaktion für die betreffende Collection aus.
Diese Form des Synchronisierens erfolgt automatisch und bedarf keiner
Einflussnahme durch den Benutzer.
Manuelles Synchronisieren
Bei der Synchronisierung können durch unvorhersehbare Fehlfunktionen,
wie z. B. ein nicht gestarteter Index-Server, fehlerhafte Netzwerkverbindungen zum Index-Server usw., bestimmte Probleme auftreten. In diesen
Fällen ist ein automatisches Synchronisieren nicht möglich.
Um auch im Fehlerfall die Konsistenz der Datenbestände zu gewährleisten, gibt es die Funktion des manuellen Synchronisierens einer Collection. Das manuelle Synchronisieren ist auch bei Konfigurationsänderungen einer Collection erforderlich, um die Collection der neuen
Konfiguration anzupassen.
Das manuelle Synchronisieren starten Sie mithilfe des Admin-Clients. Der
Synchronisierungsvorgang wird intern durch den Agenten “ContentMinerBenachrichtigung” ausgeführt, und zwar jeweils auf dem Content-Server,
auf dem sich das Deploymentsystem befindet, dem die Collection zugeordnet ist.
52
Livelink WCM Server
Index-System
Hinweis: Sämtliche Aktionen und eventuell auftretende Fehlfunktionen
werden in den Protokoll- und Fehlerdateien des Content-Servers
gespeichert, auf dem sich das Deploymentsystem befindet und dem die
interne Collection zugeordnet ist. Diese Dateien liefern Ihnen im Fehlerfall nützliche Hinweise.
Weitere Informationen zum manuellen Synchronisieren finden Sie im
Abschnitt “Interne Collection synchronisieren” auf Seite 40.
4.2 Kommandozeilen-Tools
Die Kommandozeilen-Tools dienen der Verwaltung externer Collections.
Sie erfüllen folgende Funktionen:

Indexieren von Dokumenten für externe Collections

Ermitteln von Informationen über externe Collections und über das
verwendete Index-System
Hinweis: Die Verwendung von Kommandozeilen-Tools ist nicht auf
externe Collections beschränkt. Die Tools, die nur lesend auf den Index
zugreifen (z. B. GetAvailableCollections, GetVersion) können auch
für interne Collections sinnvoll eingesetzt werden. Die Anwendung von
Tools, die schreibend auf den Index zugreifen, ist hingegen für interne
Collections nicht sinnvoll, da diese Daten beim Synchronisieren der
Collection verloren gehen.
Die Kommandozeilen-Tools befinden sich für jeden installierten Suchserver als ausführbare Skripte (.bat bzw. .sh) im Verzeichnis
{Speicherort des Index}\contentminer\{Suchservername}\
tools\.
53
Kapitel 4
Um die Kommandozeilen-Tools auszuführen, müssen entsprechende
Parameter angegeben werden, die zur Steuerung des Kommandos erforderlich sind. Durch die Parameterangaben wird einerseits festgelegt,
welcher Server die Verarbeitung des Kommandos übernehmen soll, andererseits enthalten die Parameter notwendige Informationen über die
eigentliche Indexierungsaktion.
Die Parameter der Kommandos, die den Server bestimmen, sind für jedes
Kommandozeilen-Tool identisch. Aus diesem Grund kann der Aufruf der
Kommandozeilen-Tools in der Hinsicht vereinfacht werden, dass diese
Standardparameter in einer Konfigurationsdatei festgelegt werden und
diese Datei als Aufrufparameter angegeben wird.
Hinweis: Fast alle kommandospezifischen Parameter können in der
Konfigurationsdatei spezifiziert werden. Es empfiehlt sich jedoch, in der
Datei nur die Parameter anzugeben, die selten Änderungen
unterliegen.
Konfigurationsdatei c omma nds . pr ope r ti es
Standardmäßig wird bei der Installation die Konfigurationsdatei
commands.properties mit den Kommandozeilen-Tools im Verzeichnis
{WCM-Installationsverzeichnis}\contentminer\{Suchservername}\tools\ gespeichert. In der Datei sind Standardparameter
enthalten, die den Angaben entsprechen, die bei der Installation vorgenommen wurden. Die Konfigurationsdatei könnte folgendermaßen
aussehen:
#------------------------------------------------------# Extract from configuration file commands.properties
#------------------------------------------------------# basic values for connection - should not be changed
host
=
wcmserver.company.example
vipp
=
5004
http
=
5005
server
=
searchserver1
54
Livelink WCM Server
Index-System
ssl
...
=
false
Hinweise

Für die Konfigurationsdatei der Kommandozeilen-Tools gilt die
Syntax von Java-Properties-Dateien. Parameter sind in der
folgenden Form anzugeben:
{Schlüssel} = {Wert}

Im Unterschied zu den Angaben in der Kommandozeile werden die
Schlüssel (Parameterbezeichner) in der Konfigurationsdatei ohne
vorangestelltes Minuszeichen (-) angegeben.

Parameterangaben in der Kommandozeile haben Vorrang vor den
entsprechenden Angaben in der Konfigurationsdatei.
Allgemeine Parameter der KommandozeilenTools
Die im Folgenden beschriebenen Parameter gelten für alle Kommandos.
Mit ihnen werden allgemeine Einstellungen sowie das grundsätzliche
Verhalten des jeweiligen Kommandos festgelegt.
Für jeden Parameter werden neben seiner Bedeutung bei der Steuerung
auch die Kurzform (Alternative) – sofern vorhanden – angegeben sowie
Informationen darüber, ob der Parameter optional oder obligatorisch ist.
Wird ein Parameter nicht angegeben, wird auf den entsprechenden
Eintrag in der Datei commands.properties zurückgegriffen.
55
Kapitel 4
Tabelle 2 – Allgemeine Parameter der Kommandozeilen-Tools
Parameter
Alternative
Optional
Beschreibung
-help (ohne Wert)
Ja
Hilfetext: zeigt einen Hilfetext mit Angabe der für das Kommando gültigen Parameter. Das Kommando wird mit diesem Parameter nicht ausgeführt.
Der Parameter kann nicht in der Properties-Datei angegeben werden.
-conf
Ja
Configuration File: Name der Konfigurationsdatei. Mit diesem Parameter kann
der Name bzw. der Ort der Konfigurationsdatei angegeben werden. Wird der
Parameter nicht angegeben, wird die Datei im aktuellen Verzeichnis und mit
dem Namen commands.properties erwartet.
-noconf (ohne Wert)
Ja
No Configuration File: keine Konfigurationsdatei. Unterbindet die Benutzung
der Konfigurationsdatei bei der Ausführung des Kommandos.
-noout (ohne Wert)
Ja
No Output File: keine Ergebnisausgabe. Unterdrückt die Ausgabe von Ergebnissen des Kommandos.
-host (ohne Wert)
Nein
Host: Hostname des Content-Servers, auf dem der Suchserver, der das
Kommando ausführen soll, läuft. Die Information wird in der Form
“{Hostname}.{Domain}” angegeben. Der Wert des Parameters liefert
zusammen mit den Werten der Parameter -vipp und -http die notwendigen
Informationen zur Kommunikation mit dem WCM-Server.
56
Livelink WCM Server
Index-System
Parameter
Alternative
Optional
Beschreibung
-vipp
Nein
VIPP-Port: Port des Content-Servers für die TCP/IP-Verbindung (siehe auch
-host)
-http
Nein
HTTP-Port: Port des Content-Servers für die HTTP-Verbindung (siehe auch
-host)
-server
Nein
Suchserver: Name des Suchservers, der das Kommando ausführen soll
-ssl
Nein
SSL: Angabe, ob die Kommunikation mit dem Content-Server über gesicherte
Verbindungen (Secure Socket Layer) erfolgen soll. Mögliche Werte sind true
und false.
Ausgabe der Kommandozeilen-Tools
In der Ausgabe der Kommandozeilen-Tools wird zunächst eine Liste der
Parameter angezeigt, die für die Ausführung des betreffenden
Kommandos verwendet werden. Für Kommandos, die Informationen
auslesen, wird zusätzlich die angeforderte Information aufgelistet.
Wenn ein Kommando nicht ausgeführt werden kann, wird eine Fehlerbeschreibung ausgegeben, die Informationen über die Ursache enthält.
57
Kapitel 4
AddDocument
AddDocument dient zum Hinzufügen eines einzelnen, durch seinen Pfad
spezifizierten Dokuments zu einer Collection.
Tabelle 3 – Parameter des Kommandozeilen-Tools AddDocument
Parameter
Alternative
Optional
-id
Nein
Beschreibung
-LuceneCollectionID
Lucene Collection ID: Name der Collection, zu der das Dokument hinzugefügt
werden soll
-Url
Nein
URL: voll qualifizierte URL des Dokuments, das hinzugefügt werden soll
-Path
Nein
Path: vollständiger Pfad im Dateisystem zu dem Dokument, das hinzugefügt
werden soll
Beispiel
AddDocument -host wcmserver.company.example -vipp 5004 -http 5005
-server Lucene-Suchserver -LuceneCollectionID InternetSite
-Url http://wcmserver.company.example/wcm/InternetSite_edit/
index.html
-Path c:\webserver\InternetSite\index.html
Ausgabe
Es werden die verwendeten Parameter und der Name der Collection als
Bestätigung der erfolgreichen Ausführung des Kommandos ausgegeben.
58
Livelink WCM Server
Index-System
Verwendete Parameter fuer das Kommando 'AddDocument'
host: wcmserver.company.example
vipp: 5004
http: 5005
server: Lucene-Suchserver
ssl: false
Path: c:\webserver\InternetSite\index.html
Url: http://wcmserver.company.example/wcm/InternetSite_edit/index.html
LuceneCollectionID: InternetSite
DeleteDocument
DeleteDocument entfernt das spezifizierte Dokument aus einer Collection.
Tabelle 4 – Parameter des Kommandozeilen-Tools DeleteDocument
Parameter
Alternative
Optional
-id
Nein
Beschreibung
-LuceneCollectionID
Lucene Collection ID: Name der Collection, aus der das Dokument entfernt
werden soll
-Path
Nein
Path: vollständiger Pfad im Dateisystem zu dem Dokument, das aus der Collection gelöscht werden soll. Das Dokument muss vorher mittels AddDocument
oder AddDirectory zur Collection hinzugefügt worden sein.
59
Kapitel 4
Beispiel
DeleteDocument -host wcmserver.company.example -vipp 5004 -http 5005
-Path c:\webserver\InternetSite\index.html
Ausgabe
Verwendete Parameter fuer das Kommando 'DeleteDocument'
vipp: 5004
http: 5005
ssl: false
Path: c:\webserver\InternetSite\index.html
AddDirectory
Mittels AddDirectory können Dokumente aus Verzeichnissen zu einer
Collection hinzugefügt werden. Die einzelnen Dokumente eines hinzugefügten Verzeichnisses sind nach Ausführung des Kommandos Bestandteil
des Index.
60
Livelink WCM Server
Index-System
Tabelle 5 – Parameter des Kommandozeilen-Tools AddDirectory
Parameter
Alternative
Optional
-id
Nein
Beschreibung
-LuceneCollectionID
Lucene Collection ID: Name der Collection, zu der Dokumente aus einem
Verzeichnis hinzugefügt werden sollen
-DirectoryUrl
-dirUrl
Nein
Directory URL: URL des mit dem Parameter -Directory angegebenen
Verzeichnisses, über die mit einem Webserver auf das Verzeichnis zugegriffen
werden kann
-Directory
-dir
Nein
Directory: Pfad des Verzeichnisses, das rekursiv indexiert werden soll. Unterverzeichnisse werden ebenfalls indexiert.
Beispiel
AddDirectory -host wcmserver.company.example -vipp 5004 -http 5005
-DirectoryUrl http://wcmserver.company.example/wcm/
InternetSite_edit
-Directory c:\Webserver\InternetSite
Ausgabe
61
Kapitel 4
Verwendete Parameter fuer das Kommando 'AddDirectory'
vipp: 5004
http: 5005
ssl: false
DirectoryUrl: http://wcmserver.company.example/wcm/InternetSite_edit
Directory: c:\webserver\InternetSite
DeleteDirectory
DeleteDirectory entfernt die Dokumente eines Verzeichnisses, das
mittels AddDirectory zu einer Collection hinzugefügt wurde, aus der
Collection.
Tabelle 6 – Parameter des Kommandozeilen-Tools DeleteDirectory
Parameter
Alternative
Optional
-id
Nein
Beschreibung
-LuceneCollectionID
Lucene Collection ID: Der Name der Collection, aus der Dokumente aus einem
Verzeichnis entfernt werden sollen
-Directory
-dir
Nein
Directory: Wurzel des Verzeichnisbaums, dessen Dokumente aus der Collection gelöscht werden sollen. Dabei muss der Wert des Parameters ein
Verzeichnis enthalten, das mittels AddDirectory in die Collection aufgenommen wurde.
62
Livelink WCM Server
Index-System
Beispiel
DeleteDirectory -host wcmserver.company.example -vipp 5004 -http 5005
-Directory c:\Webserver\InternetSite
Ausgabe
Verwendete Parameter fuer das Kommando 'DeleteDirectory'
vipp: 5004
http: 5005
ssl: false
Directory: c:\webserver\InternetSite
GetAvailableCollections
GetAvailableCollections gibt eine Liste aller aktuell verfügbaren Collections mit der Anzahl der in ihrem Index enthaltenen Dokumente aus.
Beispiel
GetAvailableCollections -host wcmserver.company.example -vipp 5004
-http 5005 -server Lucene-Suchserver
Ausgabe
Es werden die verwendeten Parameter und eine Liste der Collections mit
der jeweiligen Anzahl der indexierten Dokumente ausgegeben.
63
Kapitel 4
Verwendete Parameter fuer das Kommando 'GetAvailableCollections'
vipp: 5004
http: 5005
ssl: false
----------------------------------------------------------------------InternetSite: 518
CompanyIntranet: 233
GetVersion
GetVersion gibt die Versionsnummer des Index-Servers aus.
Beispiel
GetVersion -host wcmserver.company.example -vipp 5004 -http 5005
-server Lucene-Suchserver
Ausgabe
Es werden die verwendeten Parameter und die Versionsnummer des
Index-Servers ausgegeben.
Verwendete Parameter fuer das Kommando 'GetVersion'
vipp: 5004
http: 5005
ssl: false
----------------------------------------------------------------------Version = 1.3
64
Livelink WCM Server
Index-System
4.3 File-Handles
Eine Collection wird im Dateisystem durch eine bestimmte Menge von
Dateien repräsentiert. Insbesondere auf Windows-Plattformen ist dabei
die Anzahl der benötigten File-Handles zu berücksichtigen, da diese eine
vom Betriebssystem vorgegebene Grenze nicht überschreiten dürfen.
Die Anzahl der Dateien ist abhängig von der Zahl der so genannten
Segmente, aus denen sich die Collection zusammensetzt. Die Anzahl der
Dateien pro Segment unterscheidet sich für externe und interne Collections: Für externe Collections werden 10 Dateien benötigt, für interne Collections standardmäßig 14 Dateien, wobei jedes indexierte Metadatenfeld
eine zusätzliche Datei benötigt.
Hinweise

Um die Anzahl der benötigten File-Handles für interne Collections zu
minimieren, nehmen Sie möglichst wenig Metadaten in den Index
auf. Jedes zusätzlich indexierte Metadatum benötigt ein weiteres
File-Handle pro Segment.

Wenn Dokumente zum Index hinzugefügt werden, werden gegebenenfalls neue Segmente angelegt. Durch eine Optimierung des
Indexes können Sie die Anzahl der Segmente reduzieren.

Weitere Informationen zu File-Handles und Segmenten erhalten Sie
im Internet unter http://lucene.apache.org/ sowie in der FAQ zu
Lucene unter http://wiki.apache.org/jakarta-lucene/LuceneFAQ.
65
66
Livelink WCM Server
KAPITEL 5
Query-System
5
Dieses Kapitel behandelt das Query-System. Anhand von Beispielen wird
die Implementierung von Suchanfragen beschrieben, wobei Teilbereiche
der Suche schrittweise erweitert werden.
Das Query-System dient dazu, Suchanfragen zu generieren und diese zu
verarbeiten. Es stellt folgende Komponenten bereit:

Query-Server, der die Suchanfrage annimmt und verarbeitet

Klassenbibliothek mit dem VipContentMinerBean sowie zahlreiche
Hilfsklassen zur Implementierung von Suchanfrage-Seiten (JSPSeiten)
In den folgenden Abschnitten wird der Zusammenhang der Komponenten
im Detail erläutert. Dabei wird anhand von Beispielen die Verwendung der
Content Miner-Klassen verdeutlicht. Sämtliche Beispiele finden Sie auch
im Verzeichnis {WCM-Installationsverzeichnis}\examples\
SearchServer\.
Hinweis: Eine genaue Schnittstellenbeschreibung der einzelnen
Klassen finden Sie in der Javadoc zu Content Miner.
Die folgenden Abschnitte bauen aufeinander auf, wobei zunächst eine
einfache Suche beschrieben wird und anschließend die einzelnen Teilbereiche der Suche erweitert werden. Zugunsten einer besseren Lesbarkeit
wird dabei auf die Darstellung von nicht relevantem HTML-Code
verzichtet.
Der Aufbau der Beispielbeschreibungen stellt sich wie folgt dar:
67
Kapitel 5

Ausführen einer einfachen Suche (siehe folgenden Abschnitt)

Verwenden der Konfigurationsdaten (siehe Abschnitt 5.2 “Konfigurationsdaten verwenden” auf Seite 72)

Integrieren des WCM-Systems in das Ergebnis der Suchanfrage
(siehe Abschnitt 5.3 “WCM-System in das Ergebnis der Suchanfrage
integrieren” auf Seite 76)
5.1 Einfache Suche ausführen
Den Quellcode des Beispiels finden Sie im Unterverzeichnis \simple\
des Verzeichnisses {WCM-Installationsverzeichnis}\examples\
SearchServer\.
Dieser Abschnitt behandelt folgende Vorgänge:

Erstellen eines einfachen Eingabeformulars

Instanziieren und Benutzen des VipContentMinerBean

Erstellen und Benutzen einer Query-Instanz

Anzeigen des Suchergebnisses
In der einfachsten Form setzt sich eine Suchanfrage aus zwei Komponenten zusammen: einer HTML-Seite, die ein Such-Interface beinhaltet
und einer JSP-Seite (Ergebnisseite), die die Suche ausführt und die
gefundenen Treffer auflistet.
Die Aufrufreihenfolge stellt sich wie folgt dar:
search.htm
→ result.jsp
Im folgenden Beispiel wird die Definition des Eingabeformulars dargestellt:
68
Livelink WCM Server
Query-System
Listing 1 (search.htm)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
<html>
<body>
<form name="search" method="post" action="result.jsp">
Search:<br>
<P>Server</P>
<INPUT TYPE="TEXT" SIZE="20" NAME="server">
<P>Colletion</P>
<INPUT TYPE="TEXT" SIZE="20" NAME="collection">
<P>Query</P>
<textarea NAME="query" ROWS="5" COLS="50"></textarea>
<input type="submit" value="submit">
</form>
</body>
</html>
Das Eingabeformular search.htm (Listing 1) enthält neben dem Eingabefeld für den Suchtext und einer Schaltfläche submit zwei versteckte
Datenfelder, in denen der Name der zu durchsuchenden Collection und
des zugehörigen Suchservers angegeben sind. Nach Auswahl der Schaltfläche submit wird die Ergebnisseite aufgerufen.
Listing 2 zeigt die Ergebnisseite result.jsp.
Listing 2 (result.jsp)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<html>
<body>

<%@ page language = "java"
import = "java.util.Iterator,
de.gauss.vip.contentminer.config.*,
de.gauss.vip.contentminer.query.*"
%>

<jsp:useBean
id="search"
class="de.gauss.vip.contentminer.VipContentMinerBean"
scope="session" />
69
Kapitel 5
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
70
<%
// getting request parameter
String queryStr = request.getParameter("query");
String collection = request.getParameter("collection");
String server = request.getParameter("server");
if (queryStr==null)
{
out.println("Please type in a query!");
}
else if (server.equals("change SearchServer") ||
collection.equals("change Collection"))
{
out.println("You have to modify the search page!");
}
else
{
// executing query
Query query = search.createQuery(server);
query.setCollection(collection);
query.setSearchString(queryStr);
HitList list=query.process(de.gauss.vip.portalmanager.
SessionBean.getCurrentContextId(request));
// display result
out.println("hit count: " + list.size() + "<br>");
Iterator iter = list.values().iterator();
int k=0;
while (iter.hasNext())
{
k++;
HitDocument doc=(HitDocument)iter.next();
String url=doc.getUrl();
String score=doc.getProperty(HitDocument.DOC_SCORE, "");
String title=doc.getProperty(HitDocument.DOC_TITLE, url);
out.println(k + ". Score: "+ score);
out.println("<a href=\""+url+"\">"+title+"</a><br>");
}
}
%>
</body>
</html>
Livelink WCM Server
Query-System
Die Ergebnisseite result.jsp (Listing 2) definiert zunächst die auszugebende Seite (Zeilen 4–9). In den Zeilen 11–15 wird das
VipContentMinerBean mit dem Scope “Session” instanziiert, das den
Startpunkt für jede Suche darstellt.
In Zeile 17 ff. findet die eigentliche Verarbeitung statt. Zuerst werden
dabei die Übergabeparameter übernommen und geprüft (Zeile 19 ff.). Die
Übergabeparameter entsprechen den im HTML-Formular definierten
Feldern. Im Fall ungültiger Parameter wird die Verarbeitung mit einer
Exception abgebrochen.
In Zeile 35 wird über das VipContentMinerBean eine Query-Instanz
erzeugt, über die die eigentliche Suche durchgeführt wird. Vor dem
Ausführen der Query (Zeile 38) wird diese mit Informationen versorgt, die
für das Ausführen relevant sind. In diesem Beispiel werden die Collection
und der eingegebene Such-String gesetzt. Als Ergebnis erhält der
Programmierer eine Trefferliste in Form einer HitList.
Zuletzt wird die Trefferliste ausgewertet. Dies erfolgt in Zeile 41 ff. Die
Anzahl der Treffer wird ausgegeben und die Trefferliste in einer Schleife
abgearbeitet (Zeile 44 ff.). Die Trefferliste verhält sich dabei wie eine
normale Collection aus dem WCM Java API. Über einen Iterator wird
jedes Dokument in der Trefferliste durchlaufen (Zeile 47) und einzeln
ausgegeben (Zeile 52 f.).
Hinweis: Sie können mit dem Search Server Connector für Lucene
auch Metadaten von WCM-Objekten suchen. Informationen zum
Formulieren einer entsprechenden Suchanfrage finden Sie in Abschnitt
“Felder (Fields)” auf Seite 86.
71
Kapitel 5
5.2 Konfigurationsdaten verwenden
Den Quellcode des Beispiels finden Sie im Unterverzeichnis \config\ des
Verzeichnisses {WCM-Installationsverzeichnis}\examples\
SearchServer\.
Der Abschnitt behandelt folgende Punkte:

Ermitteln der installierten Suchserver

Ermitteln der verfügbaren Collections
Über das VipContentMinerBean hat der Programmierer Zugriff auf alle
Konfigurationsdaten von Content Miner. Das Bean bietet Zugriffsmethoden an, mit denen auf Suchserver und deren Collections zugegriffen
werden kann.
Die Listings 3, 4 und 5 erweitern das obige Beispiel um die Funktionalität,
den Suchserver und eine zugehörige Collection über eigene Formulare
auszuwählen.
server.jsp
→ collection.jsp → search.jsp → result.jsp
Listing 3 zeigt das Formular server.jsp zur Auswahl des Servers.
Listing 3 (server.jsp)
1
2
3
4
5
6
7
8
9
10
11
12
13
72
<html>
<body>

<%@ page language = "Java"
import = "java.util.List,
de.gauss.vip.contentminer.config.SearchServer"
%>
<jsp:useBean id="search"
scope="session" />
Livelink WCM Server
Query-System
14
15
16
17
18
19
20
21
22
23
24
25
26
27}
28
29
30
31
32
33
34

<form action="collection.jsp" name="select server">
Select server:<br>
<%
List l=search.getSearchServers();
for (int i=0; i<l.size(); i++)
{
SearchServer server=(SearchServer)l.get(i);
%>
<br><input type="radio" name="server"
VALUE="<%= server.getServerName() %>" CHECKED>
<%= server.getServerName() %>
(servername: <%= server.getVipServerName() %>,
hostname:<%= server.getHostName() %>)<br>
<%
%>
<br>
<input type="submit" name="submit" value="next"><br>
</form>
</body>
</html>
Das Formular zur Auswahl des Servers server.jsp (Listing 3) enthält
eine Liste aller verfügbaren Suchserver. Aus dieser Liste kann ein Suchserver ausgewählt werden. Nach Auswahl der Schaltfläche next wird das
nächste Formular aufgerufen, das die zugehörigen Collections auflistet.
Nach der Seitendefinition und der Instanziierung des
VipContentMinerBean (Zeile 4 ff.) werden vom VipContentMinerBean
alle verfügbaren Suchserver ermittelt (Zeile 18). Die zurückgegebene
Liste wird anschließend durchlaufen und der jeweilige Suchserver extrahiert (Zeile 19 ff.). Die Ausgabe als Formularelement erfolgt in Zeile 23 ff.
Im folgenden Quellcode wird das Formular collection.jsp zur Auswahl
der Collection dargestellt.
Listing 4 (collection.jsp)
1
2
<html>
<body>
73
Kapitel 5
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
<%@ page language = "Java"
import = "java.util.List, java.util.Iterator,
de.gauss.vip.contentminer.config.Collection"
%>
<jsp:useBean id="search"
scope="session" />
<form action="search.jsp" method="post" name="select collections">
<%
String server=request.getParameter("server");
%>
Select collection:<br>
<input type="hidden" name="server" value="<%= server %>">
<%
// getting collections
List l=search.getCollections(server);
for (int i=0; i<l.size(); i++)
{
Collection col=(Collection)l.get(i);
%>
<br><input type="radio" name="collection"
value="<%= col.getCollectionName() %>">
<%= col.getCollectionName() %> / <%= col.getCollectionType() %>
<%
if (col.isCollectionInternal())
{
out.println("website:"+col.getWebsiteName());
out.println(", deployment name:"
+col.getDeploymentSystemName()+ "<br>");
}
}
%>
<br>
</form>
</body>
</html>
Das Formular zur Auswahl der Collection collection.jsp (Listing 4)
ermittelt den ausgewählten Suchserver aus dem vorangegangenen
Formular und zeigt alle verfügbaren Collections an. Nach Auswahl einer
Collection und Klicken der Schaltfläche next wird das Suchformular aufge-
74
Livelink WCM Server
Query-System
rufen, in dem die eigentliche Suchanfrage eingegeben werden kann. Um
die Auswahl des Servers auch an das Suchformular weiterzuleiten, wird
zusätzlich ein verstecktes Formularfeld mit dem Servernamen in das
Formular integriert.
Nach der Seitendefinition und der Instanziierung des
VipContentMinerBean (Zeile 4 ff.) wird aus dem Request-Objekt der
Name des Suchservers ermittelt (Zeile 15). Nachdem das versteckte
Server-Feld geschrieben wurde (Zeile 18), werden über das Bean alle
Collections ermittelt, die dem Suchserver zugeordnet sind (Zeile 21). Die
zurückgegebene Liste wird anschließend durchlaufen, und die jeweiligen
Collections werden extrahiert (Zeile 22 ff.). Die Ausgabe als Formularelement erfolgt in Zeile 26 ff.
Listing 5 zeigt das Suchformular search.jsp.
Listing 5 (search.jsp)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<html>
<body>
<%@ page language = "Java"%>
<%
String collection=request.getParameter("collection");
%>
<input type="hidden" name="collection" value="<%= collection %>">
Search:<br>
<textarea NAME="query" ROWS="5" COLS="50"></textarea>
<br>
</form>
</body>
</html>
75
Kapitel 5
Das Suchformular search.jsp (Listing 5) entspricht strukturell dem Suchformular search.htm aus dem ersten Beispiel (Listing 1). Hier werden
jetzt die versteckten Felder des Formulars mit den Inhalten der vorangegangenen Formulare gefüllt (Zeile 9 f.).
Der weitere Verlauf stellt sich analog zum ersten Beispiel dar. Die Ergebnisseite result.jsp wird aufgerufen und zeigt das Ergebnis an.
5.3 WCM-System in das Ergebnis der
Suchanfrage integrieren
Den Quellcode des Beispiels finden Sie im Unterverzeichnis
\contentmanager\ des Verzeichnisses {WCMInstallationsverzeichnis}\examples\SearchServer\.
Dieser Abschnitt behandelt folgende Schwerpunkte:

Berücksichtigen eines angemeldeten Benutzers

Auswählen und Ausgeben von weiteren Tags im Suchergebnis

Setzen eines bestimmten Deploymentsystems in der
Ergebnismenge
Suchserver können durch das Anlegen interner Collections sehr eng in
das WCM-System integriert werden. Auf diese Weise stehen bei einer
Suchanfrage mehrere Funktionen zur Verfügung, die das Ergebnis einer
Suche beeinflussen können. Voraussetzung für diese Funktionen ist
jedoch, dass die zugrunde liegende Website dem entsprechenden Server
über den Admin-Client zugeordnet wurde.
Durch die Integration mit dem WCM-System können die Zugriffsrechte
des angemeldeten Benutzers berücksichtigt werden. Dabei werden bei
jeder Suche, die sich auf interne Collections bezieht, implizit die Zugriffsrechte auf den zugrunde liegenden Objekten mit berücksichtigt. Im Such-
76
Livelink WCM Server
Query-System
ergebnis sind daher nur die Treffer enthalten, für die der Benutzer eine
Zugriffsberechtigung hat. Ist der Benutzer nicht angemeldet, wird er als
anonymer Benutzer interpretiert und hat die Zugriffsrechte des Principals
“Jeder” (weitere Informationen dazu finden Sie im Content-Client-Benutzerhandbuch). Auf diese Weise können personalisierte Suchen durchgeführt werden.
Eine andere Funktion bezieht sich auf die Daten eines Treffers in einer
Treffermenge. Über das VipContentMinerBean ist es möglich, zusätzliche Attribute aus Livelink WCM Server zu setzen. Für jedes gefundene
Dokument werden diese Attribute einem HitDocument hinzugefügt. Es
können dabei alle über das WCM Java API verfügbaren Attribute
verwendet werden.
Die dritte Funktion betrifft die Manipulation der URL eines Treffers. Eine
interne Collection ist immer genau einem Deploymentsystem zugeordnet,
das die Daten für die Indexierung bereitstellt. In einer komplexen Systemumgebung können jedoch mehrere Deploymentsysteme zugunsten
einer besseren Lastverteilung parallel auf verschiedenen Rechnern eingerichtet sein. Sämtliche Deploymentsysteme beziehen sich dabei auf
dieselbe Website. In diesem Fall ist eine Indexierung aller Deploymentsysteme nicht erforderlich. Es genügt, nur ein Deploymentsystem zu indexieren.
Erfolgt eine Suche ausgehend von einem nicht indexierten Deploymentsystem auf der Collection eines indexierten Deploymentsystems, so
weisen die URLs in der Treffermenge auf das indexierte Deploymentsystem. Gewünscht ist jedoch, dass die URLs auf das Deploymentsystem
weisen, von dem aus gesucht wird. Zu diesem Zweck muss das entsprechende Deploymentsystem der Collection in der Suchanfrage zugeordnet
werden. Auf diese Weise werden die URLs der Treffermenge in die URLs
des zugeordneten Deploymentsystems umgewandelt. Wenn über
mehrere Collections gesucht wird, muss für jede Collection eine Zuordnung erfolgen. Zuordnungen werden mithilfe der Methode
Query.setProperty(collection, deployment_system) gesetzt.
77
Kapitel 5
In der Regel werden bei dem beschriebenen Szenario nur Deploymentsysteme vom gleichen Typ, z. B. “Edit”, eingesetzt. Jedoch können das
indexierte Deploymentsystem und das zugeordnete Deploymentsystem
auch von einem unterschiedlichen Typ sein, z.B. vom Typ “Edit” und
“Produktion”. In diesem Fall sind folgende Einschränkungen zu berücksichtigen: Ein Treffer, der nur im indexierten System, nicht aber im zugeordneten Deploymentsystem gefunden wird, wird aus der Treffermenge
entfernt. Dies ist z.B. der Fall, wenn das indexierte System vom Typ “Edit”
und das zugeordnete System vom Typ “QS” ist, aber das dem Trefferdokument entsprechende Objekt noch nie der Qualitätssicherung vorgelegt
worden ist. Wenn das Objekt in beiden Deploymentsystemen vorhanden
ist, aber in unterschiedlichen Versionen vorliegt, kann sich der Inhalt des
angezeigten Treffers vom Inhalt des indexierten Objekts unterscheiden.
Hinweis: Das indexierte und das zugeordnete Deploymentsystem
müssen sich immer auf dieselbe Website beziehen.
Das folgende Beispiel ermittelt die verfügbaren Suchserver und die dem
Server zugeordneten internen Collections. Bei der Eingabe einer Suchbedingung können zusätzlich durch das WCM-System verwaltete Attribute
ausgewählt werden, die im Ergebnis mit angezeigt werden sollen.
Vor dem Absetzen der eigentlichen Suche wird ein Deploymentsystem
gesetzt, für das die URLs im Ergebnis angezeigt werden sollen. Das
angezeigte Suchergebnis stellt nur die Treffer dar, für die der zurzeit angemeldete Benutzer Zugriffsrechte besitzt.
server.jsp
→ collection.jsp → search.jsp → result.jsp
Listing 6 zeigt das Suchformular search.jsp.
78
Livelink WCM Server
Query-System
Listing 6 (search.jsp)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
<html>
<body>
<%@ page language = "Java"%>
<%
String collection=request.getParameter("collection");
%>
<input type="hidden" name="collection" value="<%= collection %>">
Input: <input name="query"><br>
<br>Select WCM meta data that should be added to the search
results:<br>
<input type="checkbox" name="tag" value="acl">acl<br>
<input type="checkbox" name="tag" value="acl_owner">owner of the
acl<br>>
<input type="checkbox" name="tag" value="all_children">
all_children<br>
<input type="checkbox" name="tag" value="category">category<br>
<input type="checkbox" name="tag" value="created_by">
created_by<br>
<input type="checkbox" name="tag" value="date_created">
date_created<br>
<input type="checkbox" name="tag" value="date_expire">
date_expire<br>
<input type="checkbox" name="tag" value="date_released">
date_released<br>
<input type="checkbox" name="tag" value="date_released_at">
date_released_at<br>
<input type="checkbox" name="tag" value="deployment_hint">
deployment_hint<br>
<input type="checkbox" name="tag" value="description">
description<br>
<input type="checkbox" name="tag" value="direct_release">
direct_release<br>
<input type="checkbox" name="tag" value="email_edit">
email_edit<br>
<input type="checkbox" name="tag" value="email_qa">email_qa<br>
<input type="checkbox" name="tag" value="email_release">
email_release<br>
<input type="checkbox" name="tag" value="filename">filename<br>
<input type="checkbox" name="tag" value="keywords">keywords<br>
<input type="checkbox" name="tag" value="language">language<br>
79
Kapitel 5
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
<input type="checkbox" name="tag" value="linked_from">
linked_from<br>
<input type="checkbox" name="tag" value="links_to">links_to<br>
<input type="checkbox" name="tag" value="modified_by">
modified_by<br>
<input type="checkbox" name="tag" value="oty_name">oty_name<br>
<input type="checkbox" name="tag" value="pathname">pathname<br>
<input type="checkbox" name="tag" value="released_by">
released_by<br>
<input type="checkbox" name="tag" value="state">state<br>
<input type="checkbox" name="tag" value="sta_name">sta_name<br>
<input type="checkbox" name="tag" value="subtitle">subtitle<br>
<input type="checkbox" name="tag" value="suffix">suffix<br>
<input type="checkbox" name="tag" value="target_group">
target_group<br>
<input type="checkbox" name="tag" value="template">template<br>
<input type="checkbox" name="tag" value="title">title<br>
<input type="checkbox" name="tag" value="topic">topic<br>
<input type="checkbox" name="tag" value="type">type<br>
<input type="checkbox" name="tag" value="version">version<br>
<input type="checkbox" name="tag" value="website">website<br>
<br>
</form>
</body>
</html>
Im Suchformular search.jsp können zusätzlich zur Eingabe einer Suchanfrage (Zeile 14) noch Attribute ausgewählt werden (Zeile 16 ff.), die das
Suchergebnis ergänzen. Die eingegebenen Parameter werden anschließend an die Ergebnisseite übergeben.
Das Listing der Ergebnisseite result.jsp stellt sich wie folgt dar.
Listing 7 (result.jsp)
1
2
3
4
5
6
80
<html>
<body>

<%@ page language = "java"
import = "java.util.Iterator,
Livelink WCM Server
Query-System
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
de.gauss.lang.StringValue,
de.gauss.vip.portalmanager.SessionBean,
de.gauss.vip.contentminer.config.*,
de.gauss.vip.contentminer.query.*"
%>
<jsp:useBean
id="search"
scope="session" />
<%
String collection = request.getParameter("collection");
String server = request.getParameter("server");
String queryStr = request.getParameter("query");
if (queryStr==null)
out.println("No query string defined!");
// setting parameter
String[] tags = request.getParameterValues("tag");
if (tags!=null)
{
for (int i=0; i<tags.length; i++)
search.addDefaultAttribute(tags[i]);
}
// executing query
Query query = search.createQuery(server);
query.setCollection(collection);
query.setSearchString(queryStr);
query.setProperty(Query.DEPLOYMENT_SYSTEM,
"{VIPDEPLOYMENT_NAME}");
HitList list=query.process(SessionBean.getCurrentContextId
(request));
// display result
out.println("hit count: " + list.size());
out.println(" user: " +
SessionBean.getCurrentUserProfile(request).getUserName() +
"<br>");
Iterator iter = list.values().iterator();
int k=0;
while (iter.hasNext())
{
k++;
HitDocument doc=(HitDocument)iter.next();
String url=doc.getUrl();
String score=doc.getProperty(HitDocument.DOC_SCORE, "");
81
Kapitel 5
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
String title=doc.getProperty(HitDocument.DOC_TITLE, url);
out.println(k + ". Score: "+ score);
out.println("<a href=\""+url+"\">"+title+"</a><br>");
if (tags!=null)
{
for (int i=0; i<tags.length; i++)
{
out.println(tags[i]+"="+doc.getProperty
(new StringValue(tags[i]), ""));
}
}
out.println("<br>");
}
%>
</body>
</html>
Die Ergebnisseite result.jsp wertet die übergebenen Parameter (Zeile
20 ff.) aus dem Request-Objekt aus und ermittelt die anzuzeigenden Attribute (Zeile 28), die im VipContentMinerBean als Standardattribute
gesetzt werden (Zeile 31 f.). Anschließend wird ein Query-Objekt erzeugt
(Zeile 35), in dem das aktuelle Deploymentsystem gesetzt wird (Zeile 38),
das über ein WCM-Tag beim Generieren auf die Seite geschrieben wird.
Die Query (Zeile 39) wird mit dem aktuell angemeldeten Benutzer, der
über das SessionBean aus dem Portal Manager API ermittelt wird,
ausgeführt. Bei der Anzeige wird dieser ebenfalls über das SessionBean
angezeigt (Zeile 43). Zusätzlich zu den bereits bekannten Attributen
werden alle zusätzlich selektierten Informationen mit ausgegeben (Zeile
58 ff.).
82
Livelink WCM Server
Query-System
83
84
Livelink WCM Server
ANHANG A
Abfragesyntax
A
Zu der Volltextsuchmaschine Lucene gehört die spezielle Abfragesyntax
des so genannten Query Parsers. Mithilfe dieser Abfragesyntax können
Anfragen an das Query-System formuliert werden. Die Abfragesyntax
bietet die Möglichkeit, auch komplexe Anfragen an das Query-System zu
stellen und dadurch die in einer Collection enthaltenen Dokumente nach
verschiedensten Kriterien zu filtern.
Im Folgenden finden Sie eine Übersicht der Elemente der Abfragesyntax.
Begriffe (Terms)
Eine Suchanfrage wird unterteilt in Begriffe und Operatoren. Dabei unterscheidet Lucene zwei Arten von Begriffen:

einfache Begriffe (Terms): Ein einfacher Begriff ist ein einzelnes
Wort, z. B. Produktübersicht oder Website.

Ausdrücke (Phrases): Ein Ausdruck ist eine Gruppe von Wörtern,
die in doppelte Anführungszeichen eingeschlossen ist, z. B. “Aktuelle
Produktempfehlung”.
Um eine komplexe Anfrage zu formulieren, lassen sich verschiedene
Begriffe mithilfe von Verknüpfungsoperatoren verbinden.
85
Anhang A
Felder (Fields)
Lucene unterstützt die Suche nach Daten, die in Felder aufgeteilt sind. Bei
einer Suchanfrage können Sie entweder ein Feld angeben, in dem
gesucht werden soll, oder das Standardfeld benutzen. Die Namen der
Felder und das Standardfeld sind abhängig von der Implementierung.
Ein Feld durchsuchen Sie, indem Sie den Feldnamen eingeben, gefolgt
von einem Doppelpunkt (:) und dem Suchbegriff.
Beispiel
Der Lucene-Index enthält verschiedene Felder für die WCM-Metadaten
und das Standardfeld content für den Inhalt des WCM-Objekts. Um das
Dokument mit dem Titel “Aktuelle Produktübersicht” und dem Inhalt
“Unsere besondere Produktempfehlung lautet” zu suchen, geben Sie
folgenden Suchausdruck ein:
title:"Aktuelle Produktübersicht" AND
content:Produktempfehlung
Da das Standardfeld nicht explizit angegeben werden muss, entspricht
dies dem folgenden Suchausdruck:
title:"Aktuelle Produktübersicht" AND Produktempfehlung
Die Angabe des Feldes bezieht sich nur auf den Begriff, dem der Feldname direkt vorangestellt ist. Der folgende Suchausdruck sucht im Titel
nur nach dem Begriff “Aktuelle”; die Begriffe “Produktübersicht” und
“Produktempfehlung” werden im Inhalt des Dokuments gesucht.
title:Aktuelle Produktübersicht AND Produktempfehlung
86
Livelink WCM Server
Abfragesyntax
Suche mit Platzhaltern (Wildcards)
Lucene erlaubt die Suche mit Platzhaltern, wobei die Platzhalter als Stellvertreter für ein Zeichen oder eine Zeichengruppe eingesetzt werden
können. Mit einem Fragezeichen (?) wird genau ein Zeichen ersetzt, mit
dem Sternchen (*) mehrere Zeichen.
Hinweis: Platzhalter können innerhalb und am Ende eines Suchbegriffs
stehen, nicht jedoch am Beginn des Suchbegriffs.
Beispiel
Um nach den Begriffen “Text” und “Test” zu suchen, können Sie den
folgenden Suchausdruck verwenden:
Te?t
Nach den Begriffen “Produktübersicht” und “Produktempfehlung” suchen
Sie mithilfe des folgenden Suchausdrucks:
Produkt*
Undeutliche Suche (Fuzzy Search)
Lucene unterstützt die undeutliche Suche, basierend auf dem
Levenshtein-Distanz-Algorithmus. Um eine undeutliche Suche zu formulieren, verwenden Sie eine Tilde (~) am Ende eines einzelnen Begriffs.
Beispiel
Der Suchausdruck
lachen~
würde u.a. die Begriffe “machen”, “wachen” und “Laschen” finden.
87
Anhang A
Distanzsuche (Proximity Search)
Lucene erlaubt das Suchen von Begriffen, die eine bestimmte maximale
Distanz voneinander entfernt sind. Um eine Distanzsuche zu formulieren,
muss eine Tilde (~) gefolgt von der Anzahl der Wörter, die die Begriffe
maximal von einander entfernt sein dürfen, hinter dem Ausdruck angegeben werden.
Beispiel
Nach einem Dokument, in dem die Begriffe “Produktübersicht” und
“Produktempfehlung” innerhalb eines Abstands von 10 Wörtern
vorkommen, suchen Sie mit dem folgenden Suchausdruck:
"Produktübersicht Produktempfehlung"~10
Bereichssuche (Range Search)
Mithilfe einer Bereichssuche lassen sich die Dokumente finden, deren
Feldwerte sich innerhalb eines Suchbereichs befinden. Dabei kann angegeben werden, ob die untere und obere Grenze dieses Bereichs zum
Suchbereich gehören. Suchbereiche, die die Grenzen einschließen,
werden in eckigen Klammern angegeben. Suchbereiche, die die Grenzen
ausschließen, werden in geschweiften Klammern angegeben. Die Sortierung erfolgt lexikographisch.
Beispiel
Mit folgendem Suchausdruck suchen Sie nach allen Dokumenten, die
zwischen dem 01.09.2003 und dem 31.10.2003 angelegt wurden
(einschließlich dieser beiden Daten):
date_created:[20030901 TO 20031031]
Um alle Dokumente zu suchen, deren Titel zwischen “Aida” und “Carmen”
liegen (ausschließlich der beiden Titel), verwenden Sie folgenden Suchausdruck:
title:{Aida TO Carmen}
88
Livelink WCM Server
Abfragesyntax
Verstärkungsfaktoren
Lucene erlaubt es, einen Begriff mit einem Verstärkungsfaktor zu
versehen. Dies wirkt sich auf die Relevanz und damit auf die Reihenfolge
der Suchergebnisse aus. Um einem Begriff innerhalb einer Suchanfrage
einen Verstärkungsfaktor zuzuordnen, geben Sie hinter dem entsprechenden Begriff das Exponentialzeichen (^) gefolgt von dem Verstärkungsfaktor (Zahl größer Null) an. Standardmäßig ist der Verstärkungsfaktor 1.
Beispiel
Mit folgendem Suchausdruck suchen Sie nach den Begriffen “Produktübersicht” und “Produktempfehlung”; Suchergebnisse, die den Begriff
“Produktübersicht” enthalten, werden dabei viermal stärker gewichtet als
Suchergebnisse, die den Begriff “Produktempfehlung” enthalten.
Produktübersicht^4 Produktempfehlung
Sie können auch Ausdrücken einen Verstärkungsfaktor zuordnen:
"Produktübersicht November"^4 "Produktübersicht Oktober"
Verknüpfungsoperatoren
Mithilfe von Verknüpfungsoperatoren lassen sich die Begriffe einer Suchanfrage logisch verbinden. Die folgende Tabelle beinhaltet die Operatoren, die Lucene unterstützt.
Hinweis: Bitte beachten Sie, dass die booleschen Operatoren in Großbuchstaben geschrieben werden müssen.
89
Anhang A
Tabelle 7 – Verknüpfungsoperatoren in Suchanfragen
Operator
Alternative
Beschreibung
||
Das logische ODER dient zur Verknüpfung
mehrerer Begriffe, von denen mindestens einer im
Suchergebnis vorkommen muss.
Beispiel
OR
Hinweis: Wenn zwei Suchbegriffe durch keinen
booleschen Operator verknüpft sind, wird standardmäßig OR verwendet.
"Aktuelle Produktübersicht" OR Produktempfehlung
entspricht
"Aktuelle Produktübersicht" Produktempfehlung
AND
&&
Das logische UND dient zur Verknüpfung mehrerer
Begriffe, die alle im Suchergebnis vorkommen
müssen.
"Aktuelle Produktübersicht" AND Produktempfehlung
+
Dieser Operator (ohne Leerzeichen vor einen
Begriff gesetzt) dient dazu, den Begriff in das
Suchergebnis einzuschließen. Der Begriff muss im
Suchergebnis vorkommen.
Folgender Suchausdruck sucht nach Dokumenten, in denen “Produktempfehlung” vorkommen muss, “Produktübersicht” vorkommen kann:
+Produktempfehlung Produktübersicht
90
Livelink WCM Server
Abfragesyntax
Operator
Alternative
Beschreibung
!
Das logische NICHT dient zum Ausschließen
bestimmter Begriffe, die dann nicht im Suchergebnis vorkommen dürfen.
Beispiel
NOT
Hinweis: Dieser Operator kann nicht in Suchausdrücken mit nur einem Begriff verwendet werden.
"Produktübersicht November" NOT Produktempfehlung
Folgender Suchausdruck liefert kein Ergebnis:
NOT Produktempfehlung
Dieser Operator (ohne Leerzeichen vor einen
Begriff gesetzt) dient dazu, Begriffe aus dem Suchergebnis auszuschließen. Der Begriff darf im
Suchergebnis nicht vorkommen.
–
"Produktübersicht November" -Produktempfehlung
Gruppieren von Begriffen
Lucene erlaubt die Verwendung von runden Klammern, um Begriffe zu
gruppieren und damit Suchanfragen übersichtlich zu formulieren.
Beispiel
Mit folgendem Suchausdruck suchen Sie nach Dokumenten, die den
Begriff “Produktübersicht” und einen der Begriffe “Oktober” oder
“November” enthalten:
(Oktober OR November) AND Produktübersicht
Um nach Dokumenten zu suchen, die im Titel die Begriffe “Produktübersicht November” und “Produktempfehlung” enthalten, verwenden Sie den
folgenden Suchausdruck:
title:(+"Produktübersicht November" +Produktempfehlung)
91
Anhang A
Syntaxzeichen ausschließen
Lucene erlaubt es, Zeichen, die für die Abfragesyntax reserviert sind, in
Suchbegriffen zu verwenden. Diese Zeichen müssen mit einem
\ (Backslash = linksseitiger Schrägstrich) maskiert werden. Dies betrifft
folgende Zeichen: +, –, &&, ||, !, ( ), { }, [ ], ^, ", ~, *, ?, : und \.
Beispiel
Mit folgendem Suchausdruck suchen Sie nach Dokumenten, die den
Begriff “(1+1):2” enthalten:
\(1\+1\)\:2
92
Livelink WCM Server
Abfragesyntax
93
94
Livelink WCM Server
ANHANG B
Nicht unterstützte Funktionen des
Content Miner-API
B
Die folgende Funktionalität des Content Miner-API wird von Lucene-Suchservern nicht unterstützt (unsupported operations). Ein Aufruf der entsprechenden Methoden führt jeweils zu einer
UnsupportedOperationException.
Tabelle 8 – Unsupported Operations
Interface
Methode
SearchServer
getConceptBase()
Collection
size()
getAvailableTopics()
getAvailableIssues()
getAvailableSubjects()
getAvailableHelpers()
getAvailableCategories()
getAvailableProbes()
95
Anhang B
Interface
Methode
Query
setStrategy(String)
getStrategy()
setContextSize(String)
setAnalyzeHits(boolean)
setNoHits(boolean)
Query
setFirstHit(boolean)
setHitsPerDocument(int)
setMaxCategories(int)
setTags(String)
setSortType(String)
setTags(List)
setLocale(Locale)
getLocale()
analyze()
96
Livelink WCM Server
Nicht unterstützte Funktionen des Content Miner-API
97
98
Livelink WCM Server
Glossar
Collection – Ein Index eines Dokumentensatzes wird als Collection
bezeichnet. Es gibt interne und externe Collections. Eine interne
Collection wird aus einem Dokumentensatz gebildet, der über ein WCMSystem verwaltet wird. Eine externe Collection wird dagegen aus einem
Dokumentensatz gebildet, der durch ein beliebiges externes System
bereitgestellt wird.
Deploymentsystem – Die Deploymentsysteme erzeugen aus den WCMObjekten Seiten und verteilen die generierten Dateien in die dafür
vorgesehenen Verzeichnisse. Von dort aus werden die Dateien über den
Einsatz eines HTTP-Servers für die Benutzer sichtbar.
Deploymentsysteme können unterschiedliche Typen und Kategorien
haben.
Deploymentsystem-Kategorie – Je nach Art der Verarbeitung von
Deploymentaufträgen werden Deploymentsysteme verschiedenen
Kategorien zugeordnet: Standard-Deploymentsysteme erzeugen bei jeder
Änderung an einem WCM-Objekt automatisch eine neue Seite. Die
generierten Seiten werden im Dateisystem abgelegt. Dynamische
Deploymentsysteme generieren die Seiten auf Grundlage
benutzerdefinierter Einstellungen und nur dann, wenn die Seite über den
HTTP-Server angefordert wird. Die generierten Dateien werden in einer
flachen Dateistruktur abgelegt. Mit Suchmaschinen-Deploymentsystemen
können Sie die Daten Ihrer Website für den Einsatz einer Suchmaschine
aufbereiten. WebDAV-Deploymentsysteme bilden die Voraussetzung für
den Einsatz von WebDAV-Clients. InSite Editing-Deploymentsysteme
schaffen die Voraussetzung dafür, dass Inhalte direkt innerhalb der
Website – ohne Content-Client – bearbeitet und hinzugefügt werden
können.
Deploymentsystem-Typen – Bei Deploymentsystemen wird
entsprechend dem Staging-Konzept von Livelink WCM Server zwischen
99
Glossar
den Typen “Edit”, “QS” und “Produktion” unterschieden. Je nach Typ
werden unterschiedliche Sichten auf die Daten der Website erzeugt.
Kommandozeilen-Tool – Mithilfe von Kommandozeilen-Tools können
Indexierungsaktionen für externe Collections durchgeführt werden. Sie
ermöglichen außerdem die Ermittlung von Informationen über externe und
interne Collections sowie über das verwendete Index-System.
Master-Server – Nur Master-Server haben lesenden und schreibenden
Zugriff auf die Daten eines WCM-Systems. Der Master-Content-Server
verwaltet die Website-Daten, der Master-Administrationsserver die
Konfigurations- und Systemdaten des WCM-Systems. Siehe auch
Serverkategorie.
Proxy-Server – Ein Proxy-Server dient dazu, Anforderungen von einer
Client-Anwendung, etwa einem Browser, an einen anderen (oder mehrere
andere) Server abzufangen. Wenn der Proxy-Server die Anforderung
erfüllen kann, sendet er die angeforderten Daten an die ClientAnwendung zurück. Andernfalls leitet er die Anforderung an den
spezifizierten Server weiter.
Im Kontext von Livelink WCM Server haben WCM-Server der Kategorie
“Proxy” keinen schreibenden, sondern nur lesenden Zugriff auf die WCMObjekte bzw. die Konfiguration. Die Änderung von WCM-Objekten erfolgt
ausschließlich über den Master-Content-Server, Änderungen an der
Konfiguration des WCM-Systems sind nur über den MasterAdministrationsserver möglich. Siehe auch Serverkategorie.
Query-System – Das Query-System stellt einen Mechanismus zur
Verfügung, mit dem Suchanfragen verarbeitet und entsprechende
Trefferlisten erzeugt werden können.
Serverkategorie – In einem WCM-System wird zwischen Master- und
Proxy-Servern unterschieden. Master-Server haben schreibenden Zugriff
auf die Daten des WCM-Systems, Proxy-Server dagegen nur lesenden.
Der Master-Content-Server verwaltet die Website-Daten, der Master-
100
Livelink WCM Server
Glossar
Administrationsserver die Konfigurations- und Systemdaten. Darüber
hinaus können beliebig viele Proxy-Server eingesetzt werden.
Servertyp – Entsprechend den Aufgaben der Server gibt es zwei
Servertypen: Content-Server zur Verwaltung von Website-Daten und
Administrationsserver zur Verwaltung der Benutzer-, Konfigurations- und
Systemdaten des WCM-Systems. Jeder Content-Server ist grundsätzlich
dazu in der Lage, alle Sichten auf die Daten der verwalteten Website(s)
zur Verfügung zu stellen – Edit, QS und Produktion. Die verfügbaren
Sichten können dadurch eingeschränkt werden, dass der Content-Server
nur die Daten von bestimmten Sichten erhält.
Suchserver – Das Index- und Query-System werden innerhalb von
Livelink WCM Server unter dem Begriff “Suchserver” zusammengefasst.
Ein Suchserver ist immer genau einem WCM-Server zugeordnet. Einem
WCM-Server können auch mehrere Suchserver zugeordnet sein.
Synchronisierung – Bei der Synchronisierung wird der durch das WCMSystem verwaltete Dokumentensatz mit dem durch den Suchserver
indexierten Dokumentensatz abgeglichen. Dabei wird der Index neu
erstellt.
101
102
Livelink WCM Server
Index
A
Abfragesyntax 85
Fields 86
Fuzzy Search 87
Gruppieren von Begriffen 91
Proximity Search 88
Range Search 88
Relevanz erhöhen 89
Sonderzeichen ausschließen 92
Terms 85
Verknüpfungsoperatoren 89
Wildcards 87
AddDirectory 60
AddDocument 58
Analyzer
allgemein 43
eigene integrieren 47
mitgelieferte 46
Automatisches Synchronisieren 52
mehrere Content-Server 44
verwalten 30
commands.properties 54
Content Miner-API
nicht unterstützte Funktionen 95
Content-Server
gleiche Collection für mehrere 44
D
DeleteDirectory 62
DeleteDocument 59
Distanzsuche 88
E
Externe Collection
allgemein 17
anlegen 35
F
Begriffe (Terms) 85
Bereichssuche (Range Search) 88
Felder (Fields) 86
Fields 86
Fuzzy Search 87
C
G
Collection
beeinflussen 39
Einstellungen 36
externe Collection 17
externe Collection anlegen 35
interne Collection 17
interne Collection anlegen 31
interne Collection synchronisieren
40
komprimieren 41
löschen 38
GetAvailableCollections 63
GetVersion 64
Gruppieren von Begriffen 91
B
I
Index-System 51
Index-System (Einleitung) 18
Interne Collection
allgemein 17
anlegen 31
103
Index
synchronisieren 40
K
Kommandozeilen-Tools 53
AddDirectory 60
AddDocument 58
allgemeine Parameter 55
Ausgabe 57
DeleteDirectory 62
DeleteDocument 59
GetAvailableCollections 63
GetVersion 64
Komprimieren einer Collection 41
Konfiguration
Lucene-Suchserver 28
mehrere Content-Server für 1
Collection 44
Konfigurationsdatei
commands.properties 54
L
Löschen einer Collection 38
Lucene-Suchserver
konfigurieren 28
starten und stoppen 42
verwalten 27
M
Manuelles Synchronisieren 52
P
Parser
allgemein 43
eigene integrieren 48
mitgelieferte 48
Platzhalter (Wildcards) 87
Proximity Search 88
104
Q
Query-System 20, 67
einfache Suche ausführen 68
Konfigurationsdaten verwenden 72
WCM-System in das Suchergebnis
integrieren 76
R
Range Search 88
Relevanz 89
S
Sonderzeichen ausschließen 92
Starten
Stoppen
Suchserver 16
allgemeine Funktionsweise 15
Einstellungen 29
Integration in WCM-System 23
Synchronisieren
automatisch 52
interne Collection 40
manuell 52
Systemarchitektur 21
Deploymentsystem 22
Grundlagen 22
Master-Administrationsserver 22
Master-Content-Server 22
Proxy-Server 22
Systemverwaltung
T
Terms 85
Livelink WCM Server
Index
U
Undeutliche Suche 87
Unsupported operations 95
V
Verknüpfungsoperatoren 89
Verwalten
Collections 30
W
Wildcards 87
105

Lucene-Handbuch deutsch

Transcription

Similar documents

Beraterprofil

Worry-Free - Trend Micro

Freigabemitteilung VIP CM Suite 8.1.1

Seminar "Desktop Management" (WS 05/06)

Worry-Free™ p

Benutzungshandbuch - ISTE

Worry-FreeTM - Trend Micro