Google Search Appliance Feed Indizierung mit Mindbreeze InSpire

Konfiguration und Indizierung

Copyright ©

Mindbreeze GmbH, A-4020 Linz, .

Alle Rechte vorbehalten. Alle verwendeten Hard- und Softwarenamen sind Handelsnamen und/oder Marken der jeweiligen Hersteller.

Diese Unterlagen sind streng vertraulich. Durch die Übermittlung und Präsentation dieser Unterlagen alleine werden keine Rechte an unserer Software, an unseren Dienstleistungen und Dienstleistungsresultaten oder sonstigen geschützten Rechten begründet. Die Weitergabe, Veröffentlichung oder Vervielfältigung ist nicht gestattet.

Aus Gründen der einfacheren Lesbarkeit wird auf die geschlechtsspezifische Differenzierung, z.B. Benutzer/-innen, verzichtet. Entsprechende Begriffe gelten im Sinne der Gleichbehandlung grundsätzlich für beide Geschlechter.

Google Search Appliance FeedsPermanenter Link zu dieser Überschrift

Der Mindbreeze InSpire GSA Feed Adapter ermöglicht Google Search Appliance Feeds mit Mindbreeze InSpire zu indizieren.

Der Feed ist eine XML-Datei, die URLs enthält. Ein Feed kann außerdem auch den Inhalt der Dokumente, Metadaten und zusätzliche Informationen wie Datum der letzten Änderung enthalten. Die XML-Datei muss dem von gsafeed.dtd definierten Schema entsprechen. Diese Datei befindet sich auf der Google Search Appliance unter http://< APPLIANCE - Host-Name>:7800/gsafeed.dtd.

Die GSA Feed XML Dokumente sollten mit einem HTTP Post Request auf den GSA Feed Adapter Service Port geschickt werden. Wenn der Feed erfolgreich empfangen und bearbeitet wurde, sendet der Service den Text „Success“ mit dem Status 200.

Ein Beispiel für ein Post Request mit curl:

curl -X POST -F "data=@<feed_xml_path>"

Feed SpeicherungPermanenter Link zu dieser Überschrift

Die empfangenen GSA Feeds können für eine konfigurierten Zeitintervall gespeichert werden. Aktivieren Sie dazu die Option “Enable Feed Storage” im Abschnitt “Feed Storage Settings”. Die Option sollte als Default aktiv sein.

Wenn mit “Override Feed Storage Directory” kein Verzeichnis für die Feed Lagerung konfiguriert ist, werden die Feeds in /data/messervicedata/<serviceuid>/ abgelegt.

Mit “Schedule for cleaning up old feeds” kann bestimmt werden wie oft die veralteten Feeds gelöscht werden sollen. Für die Konfiguration muss ein Quartz-Cron Ausdruck verwendet werden.

Basiskonfiguration des GSA Feed Adapter ServicesPermanenter Link zu dieser Überschrift

In der Mindbreeze Konfiguration öffnen Sie den „Indices“ Tab. Fügen Sie einen neuen Service mit dem Symbol „Add new Service“ hinzu.

Setzen Sie den „Display Name“ und wählen Sie den Service Type „GSAFeedAdapter“ aus.

Service Settings:

  • GSA Feed Adapter Service Port: HTTP Port an den die Feed Dokumente geschickt werden können
  • „Accept Trusted Requests Only“: Wenn aktiviert, werden Feeds nur von IP Addressen welche in „Trusted Addresses“ konfiguriert sind akzeptiert.
  • „Trusted Addresses“: Enthält eine Liste von vertrauenswürdigen IP-Adressen. Wildcards werden ebenfalls unterstützt, z.B.: 192.168.116.*
  • „Use Secure Connection“: Wenn aktiviert, wird HTTPS für die Feed Services verwendet. Um HTTPS aktivieren zu können muss ein Credential mit SSL Zertifikat verfügbar sein.
  • „Server Certificate Credential“: Hier sollte das Server Zertifikat Credential für HTTPS ausgewählt werden
  • „Use Client Certificate Authentication“: Wenn aktiviert, werden Feeds nur mit Client Zertifikat Authentisierung akzeptiert. Die Client Zertifikate werden mit den installierten CA Zertifikaten validiert.
  • „Trusted CA Certificate Subject Pattern“: Regulär Ausdruck der für weitere Einschränkung der vertrauenswürdige CA Zertifikate verwendet werden kann. Es werden nur jene installierte CA Zertifikate verwendet die eine passende „Subject Distinguished Name“ Eigenschaft besitzen.
  • „Following Patterns“: Link Patterns, die nachverfolgt werden sollen
  • „Do Not Follow Patterns“: Link Patterns, die nicht nachverfolgt werden sollen
  • Document Dispatcher Thread Count: Anzahl der Threads die heruntergeladenen Dokumente bearbeiten und an die Mindbreeze Indizes weiterschicken.
  • Web Crawler Thread Count: Anzahl der Threads die URLs besuchen und um Dokumente herunterzuladen.
  • Web Crawler Queue Size: Größe des Web Crawler Dokument Queue
  • Enable FeedState CSV Logging: Wenn aktiv wird der Feed Status auch als CSV files im aktuellen Service Log Verzeichnis geloggt. Folgende CSV Files werden angelegt:
  • received-feeds.csv: Ankommende Feeds mit Feed File Path
  • processed-feeds.csv: Prozessierte Feeds mit Status
  • processed-outlinks.csv: Prozessierte URL Records mit der Anzahl von gefundenen Links
  • Full Feed Filter and Indexing Client Shutdown Timeout Seconds: Maximale Wartezeit für Full Feed Filter und Index Client Stop.
  • User Agent: Hier kann ein User Agent konfiguriert werden. Der konfigurierte User Agent wird für alle http Anfragen verwendet.
  • Ignore robots.txt Rules for Matching URLs: mit einem regulären Ausdruck kann hier bestimmt werden für welche URLs die robots.txt Regeln nicht berücksichtigt werden.
  • Minimum Delay in Milliseconds Between Consecutive HTTP Requests: Minimum Anzahl der Millisekunden zwischen aufeinanderfolgenden http Anfragen.
  • Maximum Delay in Milliseconds Between Consecutive HTTP Requests: Maximum Anzahl der Millisekunden zwischen aufeinanderfolgenden http Anfragen.
  • Try to Parse Record Metadata as Date Values: Wenn aktiv, wird es versucht mit Java Datumsformat, konfiguriert in „Parsable Date Formats (Ordered)“, ein Datumswert aus den  Feed Metadaten zu extrahieren. Die Region für die Extrahierung kann mit ein IETF BCP 47 Locale gesetzt werden in „Locale String for Date Parsing“
  • Do not replace crawler metadata with HTML meta tags: Wenn aktiv, werden die Metadaten die vom GSA Feed Adapter Service gesetzt werden nicht vom HTML Filter mit automatisch extrahierten Metadaten (HTML Meta Tags) überschrieben.

Die „Following“ bzw. „Do Not Follow“ Patterns können mit der Syntax von Google URL Patterns definiert werden:
https://www.google.com/support/enterprise/static/gsa/docs/admin/72/gsa_doc_set/admin_crawl/url_patterns.html

Collections, und Destination MappingsPermanenter Link zu dieser Überschrift

CollectionsPermanenter Link zu dieser Überschrift

Im Abschnitt „Collections“ der GSA Feed Adapter Service Konfiguration, ist es möglich URL Gruppen anhand von URL Patterns zu definieren. Ein Dokument kann zu mehreren Collections gehören, indiziert wird es aber nur einmal pro Category und Category Instance.

Die Namen von allen Collections die ein Dokument enthalten werden in das Metadatum „collections“ gespeichert.

Wenn ein Regulär Ausdruck als „Enforce Extension from URL if Matches“ Parameter gesetzt ist, wird für Dokumente mit passende URL-s die Erweiterung aus der URL abgeleitet anstatt von „Content-Type“ http Header.

Wenn eine große Anzahl von Collections oder zusätzliche Collection Eigenschaften nötig sind, können die Collections auch mit einer CSV-formatierten Konfiguration definiert werden. Die Collection Konfiguration kann aus einem File eingelesen oder direkt als Text konfiguriert werden.

Die Collection Konfiguration muss einen CSV Header mit den Eigenschaften „collectionname“ und „collectionpattern“ enthalten. Weitere Eigenschaften können auch definiert werden wie in unserem Beispiel „property1“, „property2“ und „property3“.

Die CSV Zeilen werden gruppiert nach „collectionname“. Wenn eine Collection mit mehrere URL Patterns definiert werden soll, kann die folgende Schreibweise verwendet werden:

collectionname;collectionpattern;property1;property2;property3

collection1;regexp:server1.testlab.*/.*;value1.1;value2.1;value3.1

collection1;regexp:server1.mindbreeze.*/.*

Destination MappingsPermanenter Link zu dieser Überschrift

Damit URLs in den Collections indiziert werden können, muss mindestens ein Destination Mapping definiert werden. Klicken Sie dazu auf das Symbol „Add Composite Property“ im Bereich „Destination Mapping“.

Referenzieren Sie eine oder mehrere Collections im hinzugefügte Destination Mapping („Collection Pattern“). Sie können dafür einen regulären Ausdruck angeben der auf die gewünschten Collection Namen passt.

Weiterst müssen hier die für die Indizierung verwendeten Category und Category Instance Eigenschaften definiert werden. Für Web Inhalte ist zum Beispiel die „Category“ „Web“. Die „Category Instance“ kann frei gewählt werden. Die Category Instance kann Referenzen auf definierte Collection-Eigenschaften, URL Teile und Feed Parameter enthalten.

Zuletzt ist eine Index URL und eine Filter URL wohin die Daten geschickt werden sollen.

Mit „Mindbreeze Dispatcher Thread Count“ kann man die Anzahl der Threads bestimmen die Dokumente an die konfigurierte Index- und Filter Services schicken.

Full Feed Destination MappingsPermanenter Link zu dieser Überschrift

Die Full Feed Destination Mappings sind ähnlich zu Collection-basierte Destination Mappings. Wenn Full Content Feeds indiziert werden sollen, muss die Feed Datasource als Category Instance in einem Mindbreeze Index definiert werden.

Die GSA Full Content Feeds enthalten alle Dokumente einer Datenquelle, definiert mit dem Feed „Datasource“ Eigenschaft. Es werden alle Dokumente die sich nicht in dem Feed befinden und vorher in diese Datenquelle indiziert wurden gelöscht.

Ein Full Feed Destination Mapping hat folgende Attribute:

  • Datasource: Die Feed Datasource welche an den hier konfigurierten Index geschickt werden soll. Die Dokumente werden mit dieser Category Instance indiziert.
  • Category: die Category welche für die Indizierung verwendet werden soll.
  • Index URL: Mindbreeze Index Service interne URL (http://localhost:<index_port>)
  • Filter URL: Mindbreeze Filter Service interne URL (http://localhost:<filter_port>)
  • Mindbreeze Dispatcher Thread Count: die Anzahl der Threads die Dokumente an die konfigurierte Index- und Filter Services schicken.

Wenn keine Full Feed Destination Mappings definiert sind, werden alle Feeds als inkrementell behandelt.

Metadaten ExtrahierungPermanenter Link zu dieser Überschrift

Wenn Dokumente mit dem GSA Fassadendienst indiziert werden, ist es möglich benutzerdefinierte Metadaten für die Dokumente auf verschiedene Weise zu definieren:

Metadaten definiert im Feed,

Metadaten hinzugefügt vom HTTP-Header,

Im Falle von HTML-Dokumenten, benutzerdefinierte Metadaten aus dem Inhalt.

Robots Metatags

Metadaten und URL FeedsPermanenter Link zu dieser Überschrift

Die in den URL-Records definierten Metadaten werden automatisch extrahiert und indiziert. In diesem Beispiel werden die Metadaten „meta-keywords“, „targetgroup“ und „group“ indiziert.

<record url="http://website.mycompany.com/newsletter" action="add" mimetype="text/html" lock="true" crawl-immediately="true">

         <metadata>

             <meta name="meta-keywords" content="Newsletter, My Company"/>

            <meta name="targetgroup" content="fachkunde"/>

             <meta name="group" content="public"/>

        </metadata>

</record>

Die Metadaten der Records werden nur für die Record URLs indiziert und nicht für die Unterseiten.

HTTP HeadersPermanenter Link zu dieser Überschrift

Zusätzlich zu den Metadaten aus den http Records werden für alle URLs die Metadaten aus dem X-gsa-external-metadata http Header extrahiert. Der Header enthält eine, durch Komma getrennte Liste von Werte. Alle Werte haben den Form meta-name=meta-value. Die „meta-name“ und „meta-value“ Elemente sind URL-kodiert (http://www.ietf.org/rfc/rfc3986.txt, Section 2).

ACLPermanenter Link zu dieser Überschrift

Der Mindbreeze InSpire GSA Feed Adapter unterstützt  ACL-s aus Feeds mit folgenden Einschränkungen:

  • ACL-s müssen per Record gesetzt sein
  • Geerbte ACL-s werden nicht unterstützt.
  • ACL-s aus X-google-acl Headers werden derzeit nicht berücksichtigt.

ACLs aus X-Gsa-Doc-Controls http Header werden extrahiert. Hier werden auch nur per URL gesetzte ACLs unterstützt.

Achtung! Dokumente die geerbte ACL-s in X-Gsa-Doc-Controls haben, werden per Default nicht indiziert. Wenn diese Dokumente auch indiziert werden sollen, muss die Konfigurationsoption „Index Documents with Partial Header ACL“ aktiviert werden.

Metadaten Extraktion aus dem InhaltPermanenter Link zu dieser Überschrift

Für HTML Dokumente ist es möglich benutzerdefinierte Metadaten auch aus dem Inhalt zu extrahieren, analog zum Mindbreeze Web Connector.

Wie beim Metadatum Mapping, ist es möglich für URL Collections auch “Content Extractoren“ und „Metadata Extractoren“ zu definieren.

Ein Content Extractor hat ein Collection Pattern wo ein regulärer Ausdruck konfiguriert werden kann. Auf alle URLs von allen passenden Collections werden die Regeln für Inhalt und Titel Extrahierung angewendet.

Metadata Extraktoren können auch für die Collections definiert werden. Hier ist es möglich benutzerdefinierte Metadaten mit verschiedenen Formaten und Formatierungsoptionen zu extrahieren.   

Die Metadata Extraktoren verwenden XPath Ausdrücke für das Extrahieren von textuellen Inhalten. Diese können dann formatspezifisch bearbeitet, und zum Beispiel als Datum interpretiert werden.

Collection MetadatenPermanenter Link zu dieser Überschrift

Pro Collection ist es möglich Metadaten zu definieren, die für alle zugehörige Dokumente gesetzt werden. Die Metadatenwerte können Referenzen auf definierte Collection-Eigenschaften enthalten. Im folgendem Beispiel wird der Wert für „meta2“ auf den Wert von Eigenschaft property2 der Collection gesetzt. Ein Collection Metadatum hat ebenfalls ein Collection Pattern indem ein regulärer Ausdruck konfiguriert werden kann. Auf allen Dokumenten von allen passenden Collections werden die Metadaten gesetzt.

Die Metadaten können auch Referenzen auf die folgende URL Komponente und Feed Parameter enthalten:

  • Hostname: {{urlhost}}
  • Port: {{urlport}}
  • Pfad: {{urlpath}}
  • Feed Datasource: {{datasource}}
  • Feed Type: {{feedtype}}

Collection ACLPermanenter Link zu dieser Überschrift

Analog zu Collection Metadaten ist es möglich ACL Einträge auf Collection-basis zu definieren. Die ACL Principals können ebenfalls Referenzen auf Collection-Eigenschaften enthalten. Die ACL Einträge haben auch eine „Collection Pattern“ Eigenschaft womit definiert werden kann, für welche Collections die ACL Einträge definiert werden sollen. Collection ACLs werden nur dann verwendet, wenn noch keine Feed ACL für die Dokumente definiert ist.

Die ACL Einträge können Referenzen auf die folgende URL Komponente und Feed Parameter enthalten:

  • Hostname: {{urlhost}}
  • Port: {{urlport}}
  • Pfad: {{urlpath}}
  • Feed Datasource: {{datasource}}
  • Feed Type: {{feedtype}}

URLs mit mehreren CollectionsPermanenter Link zu dieser Überschrift

Wenn ein Dokument anhand der Collection Konfiguration zu mehreren Collections gehört, werden die Collection Metadaten und Collection ACL Elemente von den passenden Collections zusammengeführt.

Es ist möglich den „Category Instance“ des Dokuments auch anhand der Collection Zugehörigkeit oder URL zu definieren. Für die Eigenschaft „Category Instance“ in der „Destination Mapping“ Konfiguration ist es möglich auch die Referenzen auf Collection Eigenschaften und URL Komponenten zu verwenden, wie in diesem Beispiel gezeigt:

Login SettingsPermanenter Link zu dieser Überschrift

Form Login und Session Verwaltung mit Cookies kann für gegebene URL Patterns mittels einer Konfiguration im CSV-format definiert werden. Die Login Konfiguration kann von einem File eingelesen oder direkt als Text konfiguriert werden.

Die Login Konfiguration muss mit folgendem Header beginnen:

urlpattern;actiontype;actionurl;logindata;followredirects;sessionlifetime

Die Login-Konfigurationszeilen enthalten Login-Aktion-Definitionen die mit der „urlpattern“ Eigenschaft gruppiert sind.

Wie in dem Header definiert, hat eine Login-Aktion folgende Eigenschaften:

  • urlpattern: ein Google URL Pattern definiert auf welche URLs die Aktion angewendet werden soll
  • actiontype: Login-Aktionstyp. Unterstützte Werte sind: GET, POST, AWS_SIGN
  • logindata: Zusätzliche Login Daten (Formularinhalt für Post oder Application Credentials für AWS_SIGN)
  • followredirects: „true“ oder „false“. Bestimmt ob die zusätzliche http Weiterleitungen automatisch verfolgt werden sollen.
  • sessionlifetime: die Lebenszeit der Sitzung in Sekunden (es gilt der erste Wert pro urlpattern).

Die unterstützte Login Aktionstypen sind:

  • POST: http Post Request auf eine URL mit einem definierten Formularinhalt. Der Text muss URL-Formkodiert sein.

Beispiel:

regexp:confluence.mycompany.com;POST;http://confluence.mycompany.com /dologin.action;os_username=user&os_password=mypassword&login=Anmelden&os_destination=%2Findex.action;false;60

  • GET: http Get Request auf eine URL.
  • Beispiel:
  • regexp:myserver.mycompany.com;GET;http://myserver.mycompany.com /sessionvalidator;;false;60
  • AWS_SIGN: Amazon Web Services Signature Version 4 für Amazon REST URLs.
  • Beispiel:
  • regexp:s3.eu-central-1.amazonaws.com;SIGN_AWS;;eu-central-1:<Access Key ID>:<Secret Key>;false;0

Wenn mehrere Login Aktionen für ein URL Pattern definiert werden sollen, muss man für die Login Aktionen dasselbe „loginpattern“ setzen.

Beispiel:

urlpattern;actiontype;actionurl;logindata;followredirects;sessionlifetime

regexp:myserver.mycompany.com;POST;http://myserver.mycompany.com /dologin.action;username=user&password=mypassword;false;60

  • regexp:myserver.mycompany.com;GET;http://myserver.mycompany.com /sessionvalidator;;false;60

Robots-Meta-TagPermanenter Link zu dieser Überschrift

Das Robots-Meta-Tag ermöglicht eine detaillierte, seitenspezifische Herangehensweise, um festzulegen, wie eine bestimmte Seite indiziert und den Nutzern in Suchergebnissen angezeigt werden soll. (https://developers.google.com/webmasters/control-crawl-index/docs/robots_meta_tag?hl=de).

Das Robots Meta Tag ist im <head> Abschnitt der jeweiligen Seite platziert:

<!DOCTYPE html>

<html>

<head>

<meta name="robots" content="noindex" />

(…)

</head>

<body>(…)</body>

</html>

Der Mindbreeze InSpire GSA Feed Adapter Service berücksichtigt den folgenden Robots-Meta-Tag Werte:

noindex: Diese Seite nicht wird nicht indiziert.

nofollow: Den Links auf dieser Seite wird nicht gefolgt.

none: Entspricht noindex, nofollow.

Collection Statistics ServletPermanenter Link zu dieser Überschrift

Auf können Statistiken zu den Collections abgeholt werden. „host“ steht dabei für den Hostnamen vom Mindbreeze InSpire Server, „port“ kann im GSA Feed Adapter Service in den „Service Settings“ mit der Option „Collection Statistics Port“ konfiguriert werden – der Standardwert ist 23850 (wenn das Textfeld leer gelassen wird).

Schaltfläche „Try download“Permanenter Link zu dieser Überschrift

Ruft man die oben genannten URL im Browser auf, bekommt man folgende Benutzeroberfläche im Browser.

Dabei wird eine Berechnung der Statistiken angestoßen. Beim Betätigen der Schaltfläche „Try download“ wird versucht, die Statistik herunterzuladen (der hinterlegte Link der Schaltfläche ist wieder ). Ist jedoch die Berechnung noch nicht fertig, bekommt man einen Status des Fortschritts der Berechnung. Bei der Berechnung wird einerseits der sogenannte Crawlerstatus für alle Dokumente geholt – dies dauert, je nach Anzahl der Dokumente im Index, mehrere Minuten bis evt. sogar Stunden. Anschließend werden die Statistiken erstellt; die Anzahl der insgesamt zu verarbeitenden Dokumente (in diesem Falls 4988) ist jedoch nur ein Schätzwert. Um den aktuellen Status der Berechnung nachverfolgen zu können, kann die Schaltfläche „Try download“ immer wieder und beliebig oft betätigt werden.

Wenn die Berechnung fertig ist und die Schaltfläche „Try download“ betätigt wird, wird die CSV-Statistik heruntergeladen. Die CSV-Datei kann dann beliebig oft heruntergeladen werden. Für jede Collection ist eine Zeile in der CSV-Datei enthalten. Die heruntergeladene Datei enthält folgende Spalten:

CollectionName

Name der Collection

Category

Category (im zugehörigen Destination Mapping konfiguriert)

CategoryInstance

Category Instance (im zugehörigen Destination Mapping konfiguriert)

IndexURL

Index URL (im zugehörigen Destination Mapping konfiguriert)

FilterURL

Filter URL (im zugehörigen Destination Mapping konfiguriert)

DocumentCount

Anzahl der Dokumente in der Collection

Timestamp

Zeitstempel (Format in ISO 8601), von welcher Zeit / Datum die Daten stammen

Schaltfläche „Recalculate“Permanenter Link zu dieser Überschrift

Wird „Recalculate“ betätigt, wird eine Neuberechnung der Statistik angestoßen. Ist jedoch gerade eine Berechnung im Gange, hat „Recalculate“ keine Auswirkungen. Mithilfe der Schaltfläche „Try download“ kann wie gehabt die CSV-Datei heruntergeladen werden bzw., falls die Berechnung noch nicht fertig ist, der Status der Berechnung abgefragt werden.

Der hinterlegte Link der Schaltfläche „Recalculate“ ist https://<host>:8443/cache/<port>/collections?datetime=. Mit dem Parameter „datetime“ kann ein Datum (im Format ISO 8601) angegeben werden, wie alt die letzte Statistik maximal sein darf. Ist die letzte berechnete Statistik neuer als das angegebene Datum, wird die Statistik heruntergeladen. Ist die letzte berechnete Statistik älter als das angegebene Datum, wird eine Neuberechnung der Statistik angestoßen. Wird der Parameter leer gelassen (also /collections?datetime=), wird das aktuelle Datum verwendet und somit immer eine Neuberechnung der Statistik angestoßen.

TIPP: Ist bereits eine Statistik erstellt worden und man gibt erneut im Browser die URL ein, wird direkt die Statistik heruntergeladen. Dies führt dazu, dass die Benutzeroberfläche mit den Schaltflächen „Recalculate“ und „Try download“ nicht angezeigt wird. Um trotzdem eine Neuberechnung der Statistik starten zu können, kann der Parameter datetime wie oben beschrieben verwendet werden.

Konfiguration des Index Services  Permanenter Link zu dieser Überschrift

Klicken Sie auf den Reiter “Indices” und dann auf das Symbol “Add new service”, um ein Index zu erstellen (optional).

Geben sie den Indexpfad (“Index Path”) ein. Falls nötig, passen Sie den Anzeigenamen („Display Name“) vom Index Service, die Index Parameter und den zugehörigen Filter Service an.

Zur Erstellung von Datenquellen für einen Index klicken Sie im Abschnitt „Data Sources“ auf „Add new custom source“.

Hier sollte für alle Kategorien die im GSA Feed Adapter Service für diesen Index zugeordnet sind eine Datenquelle konfiguriert werden (Siehe dazu Kapitel 1.2). Da die Datenquellen nur für die Suche verwendet werden, sollten die Crawler deaktiviert werden. Dazu aktivieren Sie den „Advanced Settings“ Modus und aktivieren Sie die Option „Disable Crawler“ für die konfigurierten Datenquellen:

GSA TransformerPermanenter Link zu dieser Überschrift

Der GSA Transformer ermöglicht dem Client Service, Google Search Appliance XML Anfragen zu verstehen und Google Search Appliance kompatible XML Antworten zu liefern.

Details dazu finden sich unter Google Search Appliance: Search Protocol Reference

Die Abfragen können an folgende URL gestellt werden: https://appliance/plugin/GSA/search?q=<query>

Konfiguration des GSA TransformersPermanenter Link zu dieser Überschrift

Konfiguriert wird der GSA Transformer im Client Service. Metadaten, welche immer geliefert werden sollen, können hier definiert werden.

Das Plugin wird zuerst unter „API V2 Search Request Response Transformer“ im Tab Client-Service hinzugefügt.

Konfiguration Query ConstraintsPermanenter Link zu dieser Überschrift

Es können auf den Query-String reguläre Ausdrücke (Regex) angewendet werden, um Query Constraints zu setzen. Die Query Constraints sind reguläre Ausdrücke, es werden Back-Referenzen unterstützt.

Beispiel eines möglichen Anwendungsfalles ist z.B. die Suche nach Dokumenten mit Autorennummer in unterschiedlichen Schreibweisen, die mit Constraints noch stärker eingeschränkt werden soll.

Folgende Dokumente existieren:

Document 1: author:abc_12,def_45 authorid:abc_12

Document 2: author:abc_12,def_45 authorid:abc/12

Document 3: author:abc_12,def_45 authorid:def_45

Folgende Querys werden abgesetzt

Query 1: author:abc_12

Query 2: author:abc/12

Beide Querys sollen trotz der unterschiedlichen Schreibweisen nur folgende 2 Dokumente geliefert werden:

Document 1: author:abc_12,def_45 authorid:abc_12

Document 2: author:abc_12,def_45 authorid:abc/12

Die Idee ist, mit Regex die als Trennzeichen den Unterstrich oder den Schrägstrich erkennen, zu arbeiten.

Dazu ist notwendig 3 Einstellungen zu konfigurieren:

„Query Contraints Label“ auf authorid setzen. Hinweis: Das Metadatum muss “Regex-Matchable” sein.

„Query Pattern“ auf author:(\S+)[_/](\S+) setzen

„Regex Constraint“ auf \^\\Q$1\\E[_/]\\Q$2\\E\$ setzen

Es kann auch nach nichtexistierende Metadaten gesucht werden, z.B

Query 1: writer:abc_1

Normalerweise liefert diese Query keine Resultate, da es kein Dokument mit dem Metadatum writer gibt. Das Plugin kann auch so konfiguriert werden, dass die Query selbst manipuliert wird. Dazu muss die Einstellung „Replace Matching Parts from Query“ aktiviert werden. Und die Einstellung „Replace Matching Parts from Query Value“ auf ALL gesetzt werden. Dadurch wird die Query wie folgt transformiert:

Query 1‘: ALL

Da die Constraints wie bisher gesetzt sind, werden jetzt die korrekten Dokumente geliefert.

Einstellung Name

Beschreibung

„Query Contraints Label“

Name für das Query Expression Label (Name des zu Filternden Metadatums) Hinweis: das Metadatum muss „Regex-Matchable“ sein. Die Eigenschaft muss im Category-Descriptor oder in den „Aggregated Metadata Keys festgelegt werden, ansonsten funktioniert der Constraint nicht.

Replace Matching Parts from Query“

Wenn aktiv, werden Teile der Query, die Matchen durch einen String ersetzt. Default: inaktiv

„Replace Matching Parts from Query Value“

Der Wert, der die matchenden Teile ersetzt. Default: leer. z.B. ALL

„Query Pattern“

Regulärer Ausdruck (Java) mit den die Query gematcht wird. Es können Gruppen verwendet werden. Z.B. myLabel:(\S+)[_/](\S+)

„Regex Constraint“

Regulärer Ausdruck (Mindbreeze) für den Query Constraint Regex. Referenzen auf gematchte Gruppen sind möglich mit $1 $2 … . Das Alleinstehende Sonderzeichen $ muss mit \ escaped werden. Z.B. \^\\Q$1\\E[_/]\\Q$2\\E\$

Konfiguration Standard Metadaten und Metadaten FormatePermanenter Link zu dieser Überschrift

Im Abschnitt „Metadata“ können die Standardmäßig angeforderten Metadaten konfiguriert werden.

Einstellungs Name

Beschreibung

„Metadata“

Bestimmt den Metadaten-Modus. „Disable“ fordert standardmäßig keine Metadaten an. „Send Only Configured Metadata“ fordert die konfigurierten Metadaten an. „Send Default Client Metadata When no Metadata is Configured“ fordert, wenn keine Metadaten konfiguriert sind, die Standard-Metadaten der Datenquelle an, ansonsten die konfigurierten Metadaten.

Metadata „Name“

Name des Metadatums

Metadata „Source“

Format des Metadatums. „VALUE“ oder „HTML“. „HTML“ ist die empfohlene Einstellung für Suchanwendungen, da dieses Format gut angezeigt werden kann. „VALUE“ liefert den rohen Wert des Metadatums.

Features der GSA XML SuchabfragePermanenter Link zu dieser Überschrift

Zusätzlich unterstützt der GSA Transformer folgende neuen Features der GSA XML Suchabfragen:

Request Fields

start

num

getfields

requiredfields

query operators

filter

paging

Query Term Separator Special Characters

sort

Hinweise zu getfieldsPermanenter Link zu dieser Überschrift

Der getfields Parameter bestimmt, welche Metadaten angefordert werden. Wird der getfields Parameter nicht verwendet, oder ist der getfields Wert "*", dann bestimmt die Konfiguration der Metadaten (siehe Abschnitt oben), welche Metadaten angefordert werden.

Werden mit dem getfields Parameter explizit Metadaten angefordert, z.B. mit getfields=Author.Description.Revision dann werden nur diese Metadaten angefordert, unabhängig von den konfigurierten Metadaten. Diese Metadaten werden standardmäßig im Format „HTML“ angefordert.

Das Format der angeforderten Metadaten können allerdings mit den konfigurierten Metadaten geändert werden. Ist beispielsweise das Metadatum Description mit dem Format „VALUE“ konfiguriert, dann werden mit getfields=Author.Description.Revision Metadaten in folgenden Formaten angefordert: Author in HTML, Description in VALUE, Revision in HTML.

Hinweise zu Query Term Separator Special CharactersPermanenter Link zu dieser Überschrift

In der Query können spezielle Zeichen enthalten sein, welche die Terms voneinander trennen und logische Bedeutung haben. Diese Zeichen werden geparst und die Query wird in Mindbreeze-kompatible logische Ausdrücke transformiert. Beispiele für mögliche Transformationen sind:

Query

Resultat

tree|house

tree OR house

tree -garden

tree NOT garden

tree.garden

tree AND garden

inmeta:tree

tree

description~tree

description:tree

Dieses Verhalten lässt sich deaktivieren, indem die Konfigurationsoption Parse Query Term Separator Special Characters“ deaktiviert wird. Dadurch wir die originale Query für die Suche verwendet.