Version: GSB 7Indizierung

• Überblick
• Funktionsweise des Indexerclients
• Indexertyp
• Konfiguration des Indexerclients
• Konfiguration der Solrapplikation
• Feldtypendefinition
• CAE-Konfiguration der Suche
• Indizierung von externen Downloaddokumenten

Die Indizierung von Inhalten des CMS meint hier den Prozess zur Aufbereitung von Inhalten des CMS, um deren Durchsuchbarkeit zu gewährleisten.

Überblick

Die Indizierung von Inhalten des CMS wird im GSB mit einer eigenständigen Komponente durchgeführt, welche im folgenden als Indexerclient bezeichnet wird.
Der Indexerclient kann dabei sowohl einen reinen Luceneindex, wie er bisher im GSB4.x für die Suche verwendet wurde,
mit Inhalten befüllen als auch eine Apache SolR basierte Indizierung durchführen.
Dazu verbindet sich der Indexerclient mit dem relevanten Coremedia Server (z.B. dem Master-Live Server).
In der Regel werden von dort die Inhalte bezogen, welche in der Suche auf der Webseite, also in der CAE, berücksichtigt werden sollen.

Funktionsweise des Indexerclients

Der Indexerclient bietet für die Indexierung von Inhalten zwei verschiedene Betriebsmodi an, die unabhängig vom Typ des Indexerclients (Solr, Lucene) genutzt werden können:

1. Neuaufbau ausgewählter Mandantenindizes: Die zu indexierenden Inhalte werden per Coremedia Query (Suchanfrage gegen das Repository) ermittelt und mit mehreren parallel laufenden Threads werden die gewünschten Indizes neu erzeugt. Auf diese Weise können Indizes schneller erstellt werden, als im reinen eventbasierten Verfahren (altes Verfahren im ADS). Die Neuindizierung eines Mandanten wird angestoßen, wenn im Timestampverzeichnis eine Datei vor dem Starten des Indexerclients angelegt wird (Mandant_NEW_INDEX.ni, z.B. standardlsg_NEW_INDEX.ni)
2. Eventlistenermodus: Die Aktualisierung der Indizes im laufenden Betrieb wird in diesem Modus realisiert. Dies bedeutet, dass der Client auf Events im Repository reagiert, um den Index zu aktualisieren. Bspw. wenn eine neue Version eines Dokuments erzeugt wird.

Indexertyp

Es gibt zwei Indexertypen, welche sich in der Art und Weise unterschieden, wie Inhalte indiziert werden. Zum einen ist dies die herkömmliche Lucene Indizierung, die im Wesentlichen auch bereits aus der ADS Indizierung bekannt ist.
Zum anderen gibt es jedoch auch noch die Möglichkeit die Inhalte mit Hilfe von Solr, einer dedizierten Tomcatapplikation, zu indizieren.

Lucene

Der lucenebasierte Indexerclient schreibt den Index direkt in das Dateisystem und benötigt daher keine weitere Schnittstelle, wie der solrbasierte
Indexerclient. Daher muss der Client entsprechend alle notwendigen Schritte durchführen, um die gewünschte Durchsuchbarkeit zu erreichen.
Konkret heißt dies, dass die Lucene-API im Client genutzt und konfiguriert werden muss.

Solr

Der solrbasierte Indexerclient spricht über eine HTTP Schnittstelle einen dedizierten Solr-Indexer-Tomcat an und übermittelt diesem die zu indizierenden Inhalte.
Dieser nimmt die Daten entgegen und per Konfiguration der Solrapplikation (also des Solr Tomcats) wird entschieden, wie die Inhalte aufbereitet werden.
Eine Beschreibung der prinzipiellen Konfigurationmöglichkeiten innerhalb der Solrapplikation erfolgt weiter unten.

Konfiguration des Indexerclients

Die Konfiguration und Installation des Indexerclients erfordert die folgenden allgemeinen Einstellungen. Für die jeweilige Ausprägung des Indexerclients,
also Solr bzw. Lucene, werden ebenfalls spezielle Konfigurationen benötigt, die hier noch gesondert betrachtet werden.
Konfiguriert werden diese in einer dedizierten Propertydatei für den Indexerclient. Beispiele finden sich im GSB-Kern in den Build-Property-Vorlagendateien im Ordner GSB-CD/buildProperties.

Allgemein

Property	Beschreibung	Beispiel
cap_server_http_host	CAP-Server, mit dem sich der Indexer verbindet	cap_server_http_host=content.domain.example
cap_server_http_port	CAP-Server-Port	cap_server_http_port=44441
indexer_home	Das Installationsverzeichnis in dem der Indexer installiert werden soll	indexer_home=${gsb_install_active_home}/indexer

Lucene

Eine Vorlage dafür ist auf der GSB-CD im Verzeichns buildProperties zu finden: build_indexer_lucene_example.properties

Der Typ des Indexers muss definiert werden als "lucene"
indexer_type=lucene

Solr

Eine Vorlage dafür ist auf der GSB-CD im Verzeichns buildProperties zu finden: build_indexer_solr_example.properties

Der Typ des Indexers muss definiert werden als "solr"
indexer_type=solr

Property	Beschreibung	Beispiel
indexer_solr_tomcat_host	Host ueber den der Solr-Indexer-Tomcat angesprochen werden kann	indexer_solr_tomcat_host=localhost
indexer_solr_tomcat_port	Portnummer des Solr-Indexer-Tomcats	indexer_solr_tomcat_port=9101

Konfiguration der Solrapplikation

Im Wesentlichen wird hier beschrieben, welche grundsätzlichen Möglichkeiten es bei der Konfiguration der Solrapplikation gibt.
Dazu bietet Solr hauptsächlich eine Schemadefinition (schema.xml) an in der definiert wird, welche Verarbeitungschritte durchgeführt werden,
wenn Inhalte indiziert, aber auch durchsucht werden.
Dazu gibt es in der Standardlösung ein vorkonfugiertes Schema, welches mandantenspezifisch angepasst und abgelegt werden kann.
Das Schema enthält verschieden Typen von Feldern, die bei der Indexierung und der Suche unterschiedlich gehandhabt werden.
Dies hängt vom jeweiligen Einsatzweck, bzw. Datentyp des Feldes ab. Datumsfelder, wie etwa das Erscheinungsdatum werden natürlich anders behandelt als etwa Richtextfelder,
wie z.B. der Haupttext eines Dokumentes.

Solr-Tomcatkonfiguration

Eine Vorlage dafür ist auf der GSB-CD im Verzeichns buildProperties zu finden: build_tomcat_solr_example.properties

Die Solrapplikation wird in einen ServletContainer, hier Tomcat, deployed. Für das Deployment können die folgenden Parameter über build Properties angepasst werden.

Relevant sind vor allem die Konfiguration des Ports, des Servertyps und des Solr-Cachings.

Property	Beschreibung	Beispiel
solr_server_type	Definition des Servertyps, master oder slave	solr_server_type=master
solr_max_cache_size	Anzahl der gecacheten Suchfilter etc.	solr_max_cache_size=512
solr_auto_warm_count	Wenn ein neuer Searcher geöffnet wird kann dieser schon mit einer Anzahl von Einträgen befuellt werden, die auf den Einträgen in einem alten Searcher basieren Startpunkt hier 256	solr_auto_warm_count=25
solr_max_warming_searchers	Maximale Anzahl der geöffneten Searcher - auf dem Master sollten mehr Searcher erlaubt werden als auf einem Slave - Master:5 Slave:2	solr_max_warming_searchers=5
tomcat_http_port	Definition des Ports über den der Tomcat per HTTP angesprochen werden kann	tomcat_http_port=9001

Feldtypendefinition

In der Schemadefinition der Solr-Applikation können unterschiedliche Feldtypen angelegt und verwendet werden.

Dies erfolgt  in der Datei schema.xml im Verzeichnis config/solr/multicore/MANDANT/conf, wobei alle dortigen Konfigurationsdateien vom nutzenden Mandanten überschriebenw erden können.

Exemplarisch werden im folgenden zwei Definitionen aufgeführt und deren prinzipieller Aufbau beschrieben.

Volltextfelddefintion (komplex)

<source lang="xml">

  <fieldType name="textgen" class="solr.TextField" positionIncrementGap="100">     <analyzer type="index">       <tokenizer class="solr.StandardTokenizerFactory"/>       <filter class="solr.WordDelimiterFilterFactory" generateWordParts="1" generateNumberParts="1" catenateWords="0" catenateNumbers="0" catenateAll="0" splitOnCaseChange="0"/>       <filter class="solr.LowerCaseFilterFactory"/>       <filter class="solr.SnowballPorterFilterFactory" language="German" />       <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" enablePositionIncrements="true" />       <filter class="solr.RemoveDuplicatesTokenFilterFactory" />     </analyzer>     <analyzer type="query">       <tokenizer class="solr.StandardTokenizerFactory"/>       <filter class="solr.WordDelimiterFilterFactory" generateWordParts="1" generateNumberParts="1" catenateWords="0" catenateNumbers="0" catenateAll="0" splitOnCaseChange="0"/>       <filter class="solr.LowerCaseFilterFactory"/>       <filter class="solr.SnowballPorterFilterFactory" language="German" />       <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" enablePositionIncrements="true" />       <filter class="solr.RemoveDuplicatesTokenFilterFactory" />     </analyzer>   </fieldType>

</source>

Datumsfelddefinition

<source lang="xml">

   <fieldType name="date" class="solr.TrieDateField" omitNorms="true" precisionStep="6" positionIncrementGap="0"/>

</source>

CAE-Konfiguration der Suche

Die CAE, also der Auslieferungstomcat, benötigt für die Bereitstellung der Suche je nach der zu verwendenden Suchart (Solr, Lucene) die Konfiguration für den Zugriff auf den Index.

Lucene

Da die Lucenesuche über das Dateisystem angesprochen wird muss das Verzeichnis des zu verwendenden Lucene-Indexes angegeben werden in dem die Mandantenindizes zu finden sind.
Konfiguration in den build-Properties des CAE-Tomcats::
lucene_retrieval_map_home=${indexer_home}

Hier wurde das Indexerinstallationsverzeichnis als Pfad definiert. Es kann aber natürlich jeder andere Pfad angegeben werden. Natürlich muss der Lucene-Indexerclient dann die Indizes auch dort hineinschreiben.

Solr

Im Falle des zu verwendenden Solr-Indexes muss die URL angegeben werden über den der Solrindex des Mandanten anzusprechen ist, da die Suche über HTTP angesprochen und zurückgeliefert wird.
Konfiguration in den build-Properties des CAE-Tomcats::
# Verbindungen zu solr-Servern
solr_server_connects=localhost:9101

Die bereitstellenden Solrserver können hier kommasepariert angegeben werden. Dies dient der Ausfallsicherheit.
Sollte ein Solrserver nicht mehr erreichbar sein wird vond er cae der nächste Solrserver angesprochen.

Indizierung von externen Downloaddokumenten

Der Indexerclient bietet ab dem GSB6.0.1 die Möglichkeit auch externe Downloaddokumente zu indizieren.

Voraussetzung dafür ist, dass es für jeden externen Dowload ein Dokument im Coremedia-bzw.GSB-Repository gibt (Wrapper-Dokument).
In diesem Wrapperdokument wird dann der Zugriffspfad entsprechend hinterlegt. Damit ist eine Aktualisierung der Inhalte also nur möglich wenn ein entsprechendes Event im Repository erzeugt wird:
Konkret bedeutet dies, dass eine Aktualisierung des externen Downloads nicht automatisch erkannt wird und explizit ausgelöst werden muss, indem das Wrapper-Dokument ausgeliehen und zurückgegeben bzw. publiziert wird.

Die Downloaddokumente können dabei über zwei Zugriffsmethoden eingebunden werden:

1. Per Http Adresse
2. Per lokalem File Zugriff - Files müssen direkt vom Indexerclient zugegriffen werden können

Im Indexer gibt es für diese beiden Zugriffsmethoden Größenbeschränkungen, um den performanten Betrieb des Indexers zu gewährleisten.
Diese Beschränkungen gelten für die komplette Indexerinstallation und können nicht mandantenspezifisch angepasst werden.
Per default können zunächst HTTP Downloads bis zu 20MB vorgenommen werden und lokale Dateizugriffe bis zu 50MB.Dies kann über die folgenden build-Properties des Indexers angepasst werden.

Beispiel für die Defaultwerte (Angabe immer in Bytes):

indexer_externalblob_maxsize_file=52428800
indexer_externalblob_maxsize_http=20971520

Konfiguration der Indizierung externer Downloadinhalte

Die Konfiguration der Indizierung externer Downloads erfolgt im Indexerclient mit Hilfe der Klasse: de.materna.cms.indexer.mapper.ExternalBlobMapper
Darin werden im wesentlichen die folgenden Properties definiert:

• Dokumenttypen für die eine externe Blobindizierung durchgeführt werden sollen (relevantDocTypes). Hier kann auch "all" als Wert abgelgt werden, wenn alle Dokumenttypen berücksichtigt werden sollen.
• Feld in dem der Zugriffspfad auf das externe Dokument hinterlegt ist (urlProperty)
• Name des Feldes, genauer dasr Prefix, in dem der Blobinhalt abgelegt werden soll (blobIndexPropertyNamePrefix). Dies wird wird automatisch um _blob ergänzt.
• Proxyangaben, falls HTTP Quellen angesprochen werden sollen, die über einen Proxy erreicht werden müssen (externalBlobProxyHost und externalBlobProxyPort)
• ggf. ein Prefix, welches automatisch zum Zugriffspfad ergänzt wird (externalPathPrefix)

Es folgt eine Beispielkonfiguration für den Dokumenttyp Publication und das Feld cl2ExternalFiles_ExternerDownload in der Datei standardlsg-solr-indexer.xml:

 <bean id="standardlsgExternalBlobMapper" class="de.materna.cms.indexer.mapper.ExternalBlobMapper" scope="prototype">   <property name="blobIndexPropertyNamePrefix" value="externalHttp"/>   <property name="externalBlobProxyHost" value="webproxy"/>   <property name="externalBlobProxyPort" value="8080"/>   <property name="relevantDocTypes">     <set>       <value>Publication</value>     </set>   </property>   <property name="urlProperty" value="cl2ExternalFiles_ExternerDownload"/>   <property name="externalPathPrefix" value="http://www.domain.example.de/SharedDocs/Downloads/"/> </bean>

Dabei ist zu beachten, dass cl2-Properties sich zusammensetzen aus dem Namen der cl2-Liste einem Unterstrich und dem Titel des verwendeten Linkklassifizieres.
Im obigen Beispiel also: cl2ExternalFiles_ExternerDownload
Dafür muss im ContentMapper des Mandanten konfiguriert werden, dass die cl2-Liste cl2ExternalFiles bei der Indizierung berücksichtigt wird (in cl2VirtualProperties aufnehmen) und das oben definierte Bean in externalMappers eingebunden werden. Dort können auch mehrere Konfigurationen eingebunden werden, falls z.B. dokumenttypspezifische Konfigurationen vorgenommen werden sollen. In diesem Fall muss eine weitere Bean vom Typ ExternalBlobMapper konfiguriert und eingebunden werden.

 <bean id="standardlsgContentMapper" class="de.materna.cms.indexer.mapper.ContentMapper" scope="prototype" parent="baseContentMapper">   <property name="contentHelper">      <bean class="de.materna.cms.indexer.solr.SolrContentHelper"/>   </property>   <property name="externalMappers">     <list>       <ref bean="standardlsgExternalBlobMapper"/>     </list>   </property>   <property name="cl2VirtualProperties">     <set>       <value>cl2Addresses</value>       <value>cl2Categories</value>       <value>cl2Competence</value>       <value>cl2CustServices</value>       <value>cl2DocItems</value>      <value>cl2ExternalFiles</value>       <value>cl2Fees</value>       <value>cl2Interviewee</value>       <value>cl2Location</value>       <value>cl2Memberships</value>       <value>cl2Processes</value>       <value>cl2RespTargets</value>       <value>cl2Satisfaction</value>       <value>cl2SLCategories</value>       <value>cl2Speaker</value>       <value>cl2Taxonomies</value>       </set>   </property> </bean>

Einfache Properties werden über ihren technischen Namen im Index konfiguriert. Zum Beispiel: exchangeID_str.

Das automatische Ergänzen des Prefixes über die Property externalPathPrefix ist im wesentlichen dann sinnvoll, wenn ein zentraler Downloadserver genutzt wird, oder lokale Dateien verwendet werden, die an eine Stelle im Filesystem gemounted werden. So muss im Content nur der relative Pfad angegeben werden und Änderungen an Domänen oder lokalen Dateipfaden können zentral im Client gepflegt werden und müssen nicht im Content nachgezogen werden.

Beispiel: In der Konfiguration des Indexerclients wurde als Prefix im Property externalPathPrefix http://www.domain.example.de/SharedDocs/Downloads/ konfiguriert. Im Content muss dann nur lediglich der relative Pfad angegeben werden: z.B. DE/meinDownload.pdf.

Davon unbeeinflusst ist es aber dennoch möglich absolute Http-Urls anzugeben. Dies wird erkannt und ein ggf. konfiguriertes Prefix wird dann nicht ergänzt. Der Pfad im Content muss dafür lediglich mit http beginnen.

Wird ein URL-Prefix (externalPathPrefix) für http vergeben ist es nicht möglich über dieselbe Konfiguration auch noch lokale Dateien zu indizieren, da vor den Dateipfad immer auch der http-Prefix geschrieben würde. Soll dies möglich sein sollte dafür ein dediziertes Property (oder cl2-Eintrag) genutzt werden und eine weitere entsprechende Springkonfiguration erstellt werden, wie weiter oben beschrieben. Umgekehrt ist es jedoch möglich einen Dateipfad Prefix (ebenfalls externalPathPrefix) zu vergeben und trotzdem HTTP Inhalte zu indizieren - dafür muss dann lediglich die absolute Adresse im Content angegeben werden (beginnend mit http).

Konfiguration eines cl2 Eintrages im Editor für externe Downloads

Das oben beschriebene Beispiel anhand des Eintrages cl2ExternalFiles_ExternerDownload muss entsprechend natürlich auch im Editor konfiguriert werden, damit das entsprechende Feld zur Verfügung steht. D.h. hier im konkreten Fall, dass die cl2 Liste "cl2ExternalFiles" einen weiteren Listeneintrag mit dem Linkklassifizierer "ExternerDownload" erhalten muss. Im dazugehörigen freizuschaltenden Textklassifizierer kann dann die Downloadadresse hinterlegt werden.

Blobindizierung deaktivieren

Das Blob wird nicht indiziert wenn das Dokumentproperty shoudNotBeIndexed den Wert 2 hat - analog zu Downloaddokumenten.