Dieses Kapitel beschäftigt sich mit der Einbindung der Suchmaschine Apache Solr in MyCoRe. Das MyCoRe-Release 2023.06 LTS wird erfolgreich mit Solr 8.11.4 eingesetzt und das 2024.06 LTS wird mit Solr 9.7 getestet.
Falls noch kein Solr-Server zur Verfügung steht, kann er gemäß der Anleitung im Abschnitt Einrichtung eines Solr-Servers installiert werden.
Im Zusammenhang mit der Nutzung der Properties und Kommandos zur Konfiguration von Solr-Cores in MyCoRe sind vorab einige Begiffe zu definieren.
config_set
)_default
-Template zum Erstellen eines neuen Cores eingesetzt
werden kann. Die Configuration Sets sind für alle MyCoRe-Anwendungen auf demselben Release-Stand gleich.
Seit MyCoRe 2024.06 LTS werden sie zusammen mit der MyCoRe-Solr-Komponente ausgeliefert.
core_config_type
)main
und classification
.
Der Name des Types entspricht dem Pfad zu den JSON-API-Vorlagen für das Solr-Schema in den einzelnen
MyCoRe-Modulen (z. B..../{modulname}/config/solr/{core_config_type}/solr-schema.json).
Es ist möglich, dass zwei Kerne den gleichen Typ zugewiesen haben und somit die gleichen Daten parallel in zwei Kernen indexiert werden.
core_id
)main
und classification
vergeben.
core_name
)Nun müssen für jede MyCoRe-Anwendung ein oder mehrere Solr-Cores angelegt werden. Die Konfiguration der Kerne unterscheidet sich je nach Solr Installation. Wird Solr als Cloud-Installation betrieben, so wird die Konfiguration über die seit 2024.06 LTS verfügbaren Solr-Cloud-CLI-Kommandos durchgeführt. Für eine reguläre (Standalone) Solr-Installation werden Templates (Configuration Sets) für die Basiskonfiguration durch MyCoRe über GitHub bereitgestellt oder per MyCoRe-Kommando erzeugt.
Zunächst muss die Solr-Server-URL der MyCoRe-Anwendung über ein Property
(siehe MyCoRe-Konfigurationsverzeichnis) bekannt gemacht werden.
Weiterhin können für die einzelnen CoreIds der CoreName und falls abweichend auch die Solr-URLs
definiert werden.
Die CoreId main
ist dabei immer erforderlich. Weitere CoreIds wie
classification
sind optional.
Es ist möglich, den Core auf einem anderen Solr Server zu erstellen und zu benutzen.
In diesem Fall muss das Property MCR.Solr.Core.{core_id}.ServerURL
gesetzt werden.
|
|
Alternativ können die CoreIds über die MyCoRe-CLI registriert werden. Diese Einstelllungen sind jedoch nicht persistent.
Bis MyCoRe 2023.06 LTS:
|
|
Ab MyCoRe 2024.06 LTS:
|
|
Ab Version 2024.06 bietet MyCoRe die Möglichkeit, Solr-Server mit einer Authentifizierung zu nutzen. Im Solr können fein granular für verschiedene Funktionen und Cores die benötigten Rechten konfiguriert werden. Für die Administration, Suche und Indexierung können in MyCoRe verschiedene Logins über folgende Properties gesetzt werden:
|
|
Die Authentifizierung wird über die
Basic Authentication
von Solr realisiert. Dazu wird die Konfigurationsdatei security.json
auf dem Solr Server gepflegt.
Die Authentifizierung erfolgt über das Senden eines Authorization
-Headers in den Solr-Requests.
Wenn die Properties nicht gesetzt sind, führt MyCoRe keine Authentifizierung gegenüber Solr durch.
Der Search
-Nutzer benötigt das Recht read
der Index
-Nutzer die Rechte read
und
update
und der Admin
-Nutzer das Recht all
.
Wenn mehrere Anwendungen auf den gleichen Solr-Server zugreifen, ist es ratsam, für jede Anwendung eigene Nutzer
mit den entsprechenden Rechten passend zu den jeweiligen Kernen/Collections zu erstellen.
Ab MyCoRe 2024.06 LTS können die Configsets in der Anwendung definiert und erweitert werden.
Dazu werden die benötigten Dateien im Resource-Verzeichnis eines oder mehrerer MyCoRe-Module abgelegt und
über Properties spezifiert. Über den Mechanismus "Dynamische Properties" kann die Konfiguration auch
über verschiedene Module hinweg erfolgen.
Die Default-Konfiguration kann in der MyCoRe-Solr-Komponente gefunden werden. Sie lässt sich bei Bedarf erweitern:
|
|
Base
stellt den Pfad zu den Konfigurationsdateien dar. Die Dateien welche in Files
aufgeführt sind, werden als ein
ZIP-Archiv gepackt, welches per Kommando erzeugt oder an die Solr-Cloud gesendet wird. Die Dateien werden über den
ResourceResolver-Mechanismus geladen.
Die Einrichtung der Solr-Kerne ist abhängig von der Art des Solr-Servers und des verwendeten MyCoRe-Releases.
main
wird das
mycore_solr_configset_main
benötigt.
|
|
Alternativ kann das Verzeichnis auch manuell heruntergeladen und in diesen Ordner kopiert werden.
Analog kann das Configset für den Klassifikations-Core installiert werden:
|
|
Basierend auf den bereitgestellten Configuration Sets werden nun Solr-Cores erzeugt. Als Name des main Cores kann der Name der MyCoRe-Anwendung gewählt werden.
|
|
Die MyCoRe-Config-Sets
sind direkt im Modul mycore-solr
enthalten.
Da Anwendungen die Configuration Sets erweitern (z.B. Dateien ergänzen) können, sollte das vollständige Configuration Set über die MyCoRe-Kommandozeile
generiert werden:
|
|
.../solr/server/solr/configsets/%configset_name%/conf
entpackt werden:
|
|
Basierend auf den bereitgestellten Configuration Sets werden nun Solr-Cores erzeugt. Als Name des main Cores kann der Name der MyCoRe-Anwendung gewählt werden.
|
|
Seit MyCoRe 2024.06 LTS bietet MyCoRe die Möglichkeit, die Configuration Sets direkt in die Solr-Cloud zu laden und anschließend die Kerne(Collections) zu erstellen. Hierfür wird die Solr-ConfigSet-API und die Solr-Collection-API verwendet.
Die ConfigSet-API erwartet ein ZIP-Archiv, welches die Konfigurationsdateien enthält, dass bedeutet MyCoRe muss
die Konfiguration aus einer Quelle laden können und diese in ein ZIP-Archiv packen und dieses an die Solr-Cloud
senden.
Hierfür wird das Interface MCRSolrConfigSetProvider
verwendet. Dieses Interface muss von einer
Klasse implementiert werden, die die Konfigurationen bereitstellt.
Für den Standardfall, dass die Konfigurationen aus dem Klassenpfad zu laden sind, liefert MyCoRe die Klasse
MCRSolrResourceConfigSetProvider
.
Die Configuration Sets mycore_main
und mycore_classification
sind direkt im Modul mycore-solr
enthalten
und können direkt per MyCoRe-CLI geladen werden. Wichtig ist dafür das für den passenden Kern das richtige Configuration Set
festgelegt ist. Dies kann über das Property MCR.Solr.Core.{core_id}.ConfigSetTemplate
erfolgen.
Für die Kerne main
und classification
sind die Configuration Sets mycore_main
und
mycore_classification
in der MyCoRe-Solr-Komponente vordefiniert.
|
|
Über die MyCoRe-CLI kann das Configuration Set geladen werden:
|
|
In der Solr-Cloud-Instanz können die Configuration Sets nicht für einen weiteren Kern wiederverwendet werden,
da beim Aktualisieren mit der Schema-API auch das Configuration Set modifiziert wird.
Daher werden sie in der Solr-Cloud unter einem bestimmten
modifizierten Namen abgelegt, welcher sich nach dem Muster $CoreId_$ConfigSetName
zusammensetzt. Das Configuration Set
mycore_main
wird also in der Solr-Cloud beispielsweise unter dem Namen main_mycore_main
abgelegt.
Die MyCoRe-CLI bietet die Möglichkeit, die Solr-Cores direkt in der Solr-Cloud zu erstellen. Hierfür wird die Solr-Collection-API verwendet. Folgende Kommandos können verwendet werden:
|
|
Die Collection wird mit dem Standardwert für die Anzahl der Shards erstellt.
Diese können über
das Property MCR.Solr.Core.{core_id}.ShardCount
angepasst werden.
Über die Solr-Web-Oberfläche kann geprüft werden, ob der Core richtig angelegt wurde (http://localhost:8983/solr/#/~cores).
Über das MyCoRe-Kommando
show solr configuration
kann eine Liste der zu setzenden Properties in der CLI angezeigt werden.
Da verschiedene MyCoRe Komponenten und Module individuelle Suchfelder und Datentypen benötigen, können diese direkt in den Modulen definiert werden. Mittels eines MyCoRe-Kommandos werden diese Definitonsdateien ausgelesen und über die Solr Schema API in den Core geschrieben.
Die Konfiguration der Solr-Suchfelder, Request-Handler, ... wurden seit MyCoRe 2018.06 LTS
auf die Module und Komponenten aufgeteilt, in denen sie verwendet werden. Die Basisfelder / -Konfiguration
für alle MyCoRe-Anwendungen befindet sich in der Komponente mycore-solr
.
Je nach Anwendungsfall kann es sein, dass neben dem Solr-Core vom Typ
main
weitere Definitionen für andere Core Typen (z. B.
classification
) erstellt werden müssen.
|
|
Die JSON-Dateien bestehen aus Json-Arrays, die Kommandos der Solr-Schema bzw. Solr-Configuration API
enthalten.
Sollen bereits bestehende / in MyCoRe vorhandene Felder oder ihre Definition geändert werden, kann
dies über replace
-Anweisungen in den JSON-Konfigurationsdateien erfolgen.
In Solr wird die anwenderseitige Konfiguration in der gesonderten Datei configoverlay.json
im jeweiligen Kern abgelegt. Hier können Einträge aus den Gruppen stehen, welche im Property
MCR.Solr.ObserverConfigTypes
definiert sind. Ggf. sind in diesen Definitionen auch Verweise
auf eigene Solr-FieldTypes vorhanden. Diese Elemente (z. B. ein RequestHandler) müssen beim Reload der
Solr-Kern-Konfiguration vorher gelöscht werden. Um nicht all Konfigurationen wahllos zu löschen, sind
diese im mycore.properties des jeweiligen Datenmodells explizit zum Löschen anzugeben.
|
|
Über ein MyCoRe-CLI Kommando wird die Konfiguration geladen. Im Normalfall lautet das Kommando:
|
|
Anschließend sollte noch einmal über die Solr-Web-Oberfläche geprüft werden, ob der Core vollständig konfiguriert wurde. Weiterhin sollte im MyCoRe-Log / in der Kommandozeile geprüft werden, ob Solr sämtliche Konfigurationskommandos ausgeführt hat. Ist alles okay, so ist der Core betriebsbereit.
(siehe Solr Control Script Reference, Schema API und Config API)
Standardmäßig findet die Textextraktion aus den Dokumenten innerhalb von Solr statt. Jedoch raten die Entwickler von
Solr davon ab, die Textextraktion im produktiven Betrieb zu nutzen und empfehlen die Textextraktion vorab
durchzuführen.
Hierfür kann das Property MCR.Solr.Indexer.File.AccumulatorList
genutzt werden. Dieses Property
erwartet eine Liste von Klassen, welche zusätzliche Solr-Felder aus Dateien extrahieren und für die Indexierung
bereitstellen.
Für die Textextraktion mit Tika kann die Klasse
org.mycore.solr.index.file.tika.MCRSolrRemoteTikaAccumulator
verwendet werden. Diese Klasse sendet
die Dateien an einen Tika-Server, welcher die Textextraktion durchführt. Die extrahierten Texte werden als JSON
an die MyCoRe-Anwendung zurückgegeben. Anschließend wird für jeden JSON-Key in der Antwort ein
MCRTikaMapper
verwendet, um die extrahierten Texte verschiedenen Solr-Feldern zuzuweisen.
Eine Beispielkonfiguration sieht wie folgt aus:
|
|
Der SimpleTikaMapper ist ein einfacher Mapper, welcher die extrahierten Texte in ein Solr-Feld schreibt. Ein JSON-Dokument von Tika sieht wie folgt aus:
|
|
In der Beispielkonfiguration von oben ist der Default-Mapper ein MCRTikaNOPMapper
(MCRTikaNoOperationMapper). Dieser Mapper ignoriert den JSON-Key für den es konfiguriert ist.
Für den x_tika_content
Key wird der MCRSimpleTikaMapper
verwendet. Dieser Mapper schreibt
den extrahierten Text in das Solr-Feld mit dem angepassten Namen des JSON-Keys. Dabei werden alle Zeichen die keine
Buchstaben oder Zahlen sind entfernt und der Text in Kleinbuchstaben umgewandelt. Außerdem besteht die Möglichkeit
den Namespace des JSON-Keys zu entfernen. Je nach dem ob der Wert des JSON-Keys ein Array ist, kann das Feld als
MultiValue-Feld gesetzt werden (MultiValueField=true) oder ob der Wert als String konkateniert werden soll.
Aus dem Beispiel JSON-Dokument wird also der Wert des x_tika_content
Keys in das
Solr-Feld content
geschrieben.
|
|
Die in Solr zu speichernden Daten werden als Solr-Document über eine Kette von XSLT-Transformationen generiert,
welches dann an den Solr-Server gesendet wird.
Hierfür ist das Property MCR.URIResolver.xslImports.solr-document
zuständig. Grundsätzlich in der Kette enthalten sind die Stylesheets solr-basetemplate.xsl
und mycoreobject-dynamicfields.xsl
. Weitere Transformer können dieser Kette angefügt werden (siehe
Beispielcode).
Der an Solr ausgehende Datenstrom läßt sich im Web-Browser mit der URL
https://{myapp}/receive/{mycore_id}?XSL.Style=solrdocument
überprüfen.
|
|
Über verschiedene rebuild
Kommandos (siehe Kommandos
zur Arbeit mit Solr)
können die Daten in den Solr Core eingespielt werden. Um alle Daten zu indexieren, kann beispielsweise folgendes Kommando
verwendet werden:
|
|
MyCoRe verhindert grundsätzlich den Gebrauch eigener Solr-Request-Handler solange diese nicht MyCoRe bekannt
sind. Aus Sicherheitsgründen sind zunächst nur die Handler /select
und /update
zugelassen.
Sollen weitere Handler benutzt werden, müssen diese im Property MCR.Solr.Proxy.WhiteList
hinzugefügt werden. Dies kann mit folgender Konfiguration erfolgen:
|
|
Mit Solr 8 kommt bei den Responses die Content Security Policy (CSP) im Header zum tragen. Diese Policies werden in MyCoRe an die Layout-Komponenten weiter gegeben. Nutzt die Webseite externe Referenzen, kann das zu Konflikten führen. Um die CSP zu überschreiben, wurde das folgende Property eingeführt. Es kann die CSP aus Solr ersetzen oder, wenn es leer ist, diese abschalten.
|
|
Property | Bedeutung | in App.-Config |
---|---|---|
MCR.Solr.ServerURL |
default URL für den Solr-Server, z.B.
http://mysolr.de:8983/
(ohne
/solr
am Ende)
|
required |
MCR.Solr.Core.{core_id}.Name | Name des Solr Cores (wird Pfadbestandteil der Solr-URL zum Core) | required |
MCR.Solr.Core.{core_id}.ServerURL | Basis-URL des Solr-Servers, falls der Core nicht auf dem Standard-Server (s.o.) installiert wurde | |
MCR.Solr.Core.{core_id}.ShardCount | Beim Erstellen eines Solr-Cores in der Solr-Cloud wird die Anzahl der Shards festgelegt. | optional default=1 |
MCR.Solr.Core.{core_id}.ConfigSetTemplate | Name des Configuration Sets, das für den Core verwendet werden soll | required |
MCR.Solr.ConfigSet.{config_set_id}.Class | Klasse, die die Konfigurationen für das ConfigSet bereitstellt | |
MCR.Solr.Indexer.File.AccumulatorList |
Eine Liste von Klassen, welche zusätzliche Felder für die Indexierung bereitstellen. Z.B.
org.mycore.mets.solr.MCRSolrAltoExtractor - Extrahiert Texte aus ALTO-Dateien.
|
|
MCR.Solr.Indexer.BulkSize | default=100 ; Die Anzahl der Objekte, die mit einem Mal an Solr geschickt werden. | |
MCR.Solr.Indexer.ThreadCount | default=4 ; Anzahl der benutzten Threads | |
MCR.Solr.XMLProtocolVersion | current=4.5 | |
MCR.Solr.SelectProxy.MaxConnections | default=20 ; max. Anzahl der Verbindungen zum Solr-Server für select | |
MCR.Solr.SelectPath | default=/select | |
MCR.Solr.UpdatePath | default=/update | |
MCR.Solr.ExtractPath | default=/update/extract | |
MCR.Solr.Proxy.WhiteList | default=/select ; der Proxy akzeptiert nur die Liste davon | |
MCR.Solr.SolrClient.ConnectionTimeout | default=0 | |
MCR.Solr.SolrClient.SocketTimeout | default=50000 | |
MCR.Solr.ConcurrentUpdateSolrClient.Enabled | default=true ; soll das Update parallel erfolgen? | |
MCR.Solr.ConcurrentUpdateSolrClient.QueueSize | default=100 | |
MCR.Solr.ConcurrentUpdateSolrClient.ThreadCount |
Wert entspricht dem Property
MCR.Solr.Indexer.ThreadCount
|
|
MCR.Solr.SolrInputDocument.Factory | default=org.mycore.solr.index.document.MCRSolrTransformerInputDocumentFactory | |
MCR.Solr.SolrInputDocument.Transformer | default=mycoreobject-solrdocument | |
MCR.Solr.SolrInputDocument.Path.Factory | default=org.mycore.solr.index.file.MCRSolrPathDocumentFactory | |
MCR.Solr.IndexHandler.Factory | default=org.mycore.solr.index.handlers.MCRSolrLazyInputDocumentHandlerFactory | |
MCR.Solr.FileIndexStrategy | default=org.mycore.solr.index.strategy.MCRSolrMimeTypeStrategie | |
MCR.Solr.MimeTypeStrategy.Pattern | default=image/.* | |
MCR.Solr.DynamicFields |
default=true ; erzeugt auch dynamische Felder für Solr
Es sollte geprüft werden, ob die Übertragung dynamischer Felder in der speziellen Anwendung erforderlich ist. Andernfalls sollte der Wert auf false
gestellt werden.
|
|
MCR.Solr.ContentBaseFields | eine Liste von Feldnamen für allgemeine Derivate-Metadaten | |
MCR.Solr.AVExtenderFields | eine Liste von Feldnamen für Video-Derivate-Metadaten | |
MCR.Solr.TikaFields | eine Liste von Feldnamen für Tika-Metadaten | |
MCR.Solr.JoinQueryFields |
enthält die Liste der PropertiesMCR.Solr.ContentBaseFields
,
MCR.Solr.AVExtenderFields
,
MCR.Solr.TikaFields
|
|
MCR.Solr.NestedDocuments | default=true; aktiviert den Support für Nested Documents |
|
MCR.Solr.ObserverConfigTypes | default=requestHandler,searchComponent | |
MCR.Solr.HTTPResponseHeader.Content-Security-Policy | das Property ist nicht gesetzt |
Folgende Kommandos stehen für die Arbeit mit Solr an der Kommandozeile zur Verfügung.
Achtung: Verwenden Sie bei der Arbeit mit Solr-Kommandos
die CLI (mycore.sh) stets im interaktiven Modus. Andernfalls besteht die Gefahr, dass Operationen nicht
vollständig ausgeführt werden!
Die Core ID für den Standard Solr Core in MyCoRe ist
main
.
Kommando-Name | Beschreibung |
---|---|
Zeigt die Namen der Konfigurationssets auf dem Remote-Solr-Server an. | |
Zeigt die in den MyCoRe-Einstellungen definierten Konfigurationssets an. | |
Sucht das für den angegebenen Core {0} verwendete Konfigurationsset in den MyCoRe-Einstellungen und löscht es vom Remote-Solr-Server. | |
Sucht das für den angegebenen Core {0} verwendete Konfigurationsset in den MyCoRe-Einstellungen und lädt es auf den Remote-Solr-Server hoch. | |
Erstellt eine neue Collection auf dem Remote-Solr-Server unter Verwendung des in den MyCoRe-Einstellungen definierten Konfigurationssets für den Core {0}. | |
Entfernt eine Collection auf dem Remote-Solr-Server unter Verwendung des in den MyCoRe-Einstellungen definierten Konfigurationssets für den Core {0}. |
Kommando-Name | Beschreibung |
---|---|
show solr configuration | Zeigt die MyCoRe-Properties für die aktuelle Solr-Konfiguration an. |
register solr core with name {0} as core {1} | Konfiguriert einen Solr-Core mit dem core_name {0} als core_id {1} in MyCoRe. |
add type {0} to solr core {1} | Fügt einem Solr-Core einen Typ hinzu, sodass Dokumente dieses Typs in diesem Core indexiert werden. Der Typ kann z.B. 'main' oder 'classification' sein. |
Entfernt einen Typ aus einem Solr-Core, sodass Dokumente dieses Typs nicht mehr in diesem Core indexiert werden. Der Typ kann 'main' oder 'classification' sein. | |
switch solr core {0} with core {1} | Tauscht die Konfigurationen zwischen zwei Solr-Cores aus. |
set shard count {0} for solr core {1} | Setzt die Anzahl der Shards für einen Solr-Core. Diese Anzahl wird nicht sofort auf dem Solr-Server aktualisiert, sondern verwendet, wenn der Core erstellt wird. |
set configset {0} for solr core {1} | Setzt das ConfigSet für einen Solr-Core. Das ConfigSet wird nicht sofort auf dem Solr-Server aktualisiert, sondern verwendet, wenn der Core erstellt wird. |
set server {0} for solr core {1} | Setzt den Server für einen Solr-Core. Der Server wird nicht sofort auf dem Solr-Server aktualisiert, sondern verwendet, wenn der Core erstellt wird. |
Lädt das Schema und die Konfiguration in Solr neu, indem die Solr-Schema-API für den Core mit der ID {0} verwendet wird. |
Kommando-Name | Beschreibung |
---|---|
rebuild solr metadata and content index in core {0} | Erstellt den Metadaten- und Inhaltsindex in Solr für den Core mit der ID {0} neu. |
rebuild solr metadata index for all objects of type {0} in core {1} | Erstellt den Metadatenindex in Solr für alle Objekte mit der type id {0} im Core mit der ID {1} neu. |
rebuild solr metadata index for all objects of base {0} in core {1} | Erstellt den Metadatenindex in Solr für alle Objekte mit der basis id {0} im Core mit der ID {1} neu. |
rebuild solr metadata index for object {0} in core {1} | Erstellt den Metadatenindex in Solr für das angegebene Objekt mit der id {0} im Core mit der ID {1} neu. |
select objects with solr query {0} in core {1} | Wählt MyCoRe-Objekte mit einer Solr-Abfrage {0} im Core mit der ID {1} aus. |
rebuild solr metadata index for selected in core {0} | Erstellt den Metadatenindex in Solr für ausgewählte Objekte oder Derivate im Core mit der ID {0} neu. |
rebuild solr metadata index in core {0} | Indexiert alle Objekte im Core mit der ID {0}. |
rebuild solr content index for object {0} in core {1} | Indexiert alle Derivate des Objekts mit der ID {0} im Core mit der ID {1}. |
rebuild solr content index for selected in core {0} | Indexiert alle Derivate der ausgewählten Objekte im Core mit der ID {0}. |
rebuild solr content index in core {0} | Indexiert alle Derivate in Solr im Core mit der ID {0}. |
rebuild solr classification index in core {0} | Indexier alles Klassifikationen in Solr im Core mit der ID {0} neu. |
clear solr index in core {0} | Löscht alle Einträge aus dem Index in Solr im Core mit der ID {0}. |
delete from solr index all objects of type {0} in core {1} | Löscht alle Objekte des Typs {0} aus dem Index in Solr im Core mit der ID {1}. |
delete from solr index all objects of base {0} in core {1} | Löscht alle Objekte des Basis {0} aus dem Index in Solr im Core mit der ID {1}. |
delete from solr index object {0} in core {1} | Löscht ein Objekt mit der ID {0} aus dem Index in Solr im Core mit der ID {1}. |
optimize solr index in core {0} | Optimiert den Index in Solr im Core mit der ID {0}. Diese Operation sollte aufgrund ihrer hohen Kosten selten durchgeführt werden. |
synchronize solr metadata index for all objects of type {0} in core {1} | Synchronisiert den MyCoRe-Store und den Index in Solr im Core mit der ID {1} für Objekte des Typs {0}. |
synchronize solr metadata index for all objects of base {0} in core {1} | Synchronisiert den MyCoRe-Store und den Index in Solr im Core mit der ID {1} für Objekte des Basis {0}. |
synchronize solr metadata index in core {0} | Synchronisiert den MyCoRe-Store und den Index in Solr im Core mit der ID {0}. |
Mit diesen Code-Schnipseln soll demonstriert werden, wie ein Zugriff auf die Solr-Daten mittels MyCoRe-API erfolgen kann.
|
|
Seit Version 2024.06 LTS unterstützt MyCoRe die Authentifizierung von Solr-Abfragen. Deshalb
sollte diese ab jetzt immer (unabhängig davon, ob die Authentifizierung tatsächlich konfiguriert ist) bei der Implementierung berücksichtigt werden.
Die Klasse MCRSolrAuthenticationManager
enthält Methoden, die die in MyCoRe konfigurierte Authentifizierung zu einem SolrRequest
oder zu einem HttpRequest.Builder
hinzufügen.
|
|