Was ist der SearchLayer?
In der B2B werden für verschiedene Zwecke (Volltextsuche, Archivsuche, Systemweiche, CCM) Suchindexe verwendet. Bisher wurde dies durch mehrere tausend direkte Zugriffe auf Apache Lucene core Version 2.4.1 (Lucene2) realisiert. Dadurch waren Aktualisierungen des Suchsystems sehr schwierig:
- Das Upgrade der Lucene Version war nicht möglich.
- Der Übergang auf eine andere Suchtechnologie (z.B. BDM oder ElasticSearch) war nicht möglich.
Aus diesem Grund wurde eine abstrakte Zwischenschicht, die SearchLayer API, für den Zugriff auf die Indexe definiert. Diese enthält nur etwa 30 allgemein definierte Befehle wie “search”, “update” etc. Die B2B wurde danach so umgestellt, dass sie nur noch auf diese allgemeinen Befehle zugreift. Zur Ausführung werden die Befehle dann durch den SearchLayer an eine konkrete Implementierung (derzeit Lucene2.4.1, BDM, SOLR) weitergeleitet.
Durch diese Trennschicht zwischen B2B und der konkreten Such-Technologie können demnächst mit vergleichsweise wenig Aufwand Implementierungen modernerer Suchtechnologien wie Lucene 8, ElasticSearch etc. erstellt werden.
Extension SEARCH_LAYER_CONFIGURATION
Seit Einführung der SearchLayer-API können die Systemeinstellungen der Suchtechnologie in einer neuen Extension SEARCH_LAYER_CONFIGURATION zusammengefasst werden.
Die Extension SEARCH_LAYER_CONFIGURATION muss derzeit verwendet werden, wenn Sie die Suchtechnologien LUCENE2MULTIREADER, BDM oder SOLR verwenden.
Ist die Extension nicht vorhanden, wird automatisch die Suchtechnologie Lucene2 verwendet, und es werden alle alten Einstellungen für die Indexe aus den vorhandenen GlobalProperties ausgelesen.
Aufbau der Extension
Die Extension SEARCH_LAYER_CONFIGURATION besteht aus zwei Kopfzeilen, in denen die zu verwendende Suchtechnologie (SEARCH_SYSTEM_VENDOR) sowie die vorhandenen Indexe (SEARCH_TYPES) definiert werden. Danach kommen vendor-spezifische Einstellungen. Zum Beispiel Pfade zu den einzelnen Indizies im Falle von Lucene als Vendor. Beispiele, wie die Extension aussehen kann, stehen weiter unten bei den Suchtechnologien
Suchtechnologien (SEARCH_SYSTEM_VENDOR)
| SEARCH_SYSTEM_VENDOR | Beschreibung |
|---|---|
| LUCENE2 | Implementierung der bisherigen Suchtechnologie Apache Lucene 2.4.1 |
| LUCENE2MULTIREADER | Lucene 2.4.1 Implementierung, die einen Index zum Schreiben und mehrere zum Lesen verwendet |
| BDM | Implementierung, die mit einem ElasticSearch-basierten BDM-Server arbeitet |
| SOLR | SOLR-Implementierung |
| MULTI | Implementierung zur Verwendung von zwei Indextechnologien beim Umstieg von einer Index-Technologie auf eine andere (z.B. von Lucene auf SOLR) |
Index-Typen (SEARCH_TYPES)
Derzeit können folgende SEARCH_TYPES konfiguriert werden.
| SEARCH_TYPES | Index |
|---|---|
| FULLTEXT | Volltextindex, muss konfiguriert werden |
| ARCHIVE | Archivindex |
| CCM | CCM-Index |
| SYSTEMSPLIT_METERINGPOINT | Systemweiche, Meldepunktindex |
| SYSTEMSPLIT_METERINGPOINTTEMP | Systemweiche, Meldepunktindex 2 (Rebuild) |
| SYSTEMSPLIT_RESPONSE | Systemweiche, Antwortindex |
Index-Definitionen
LUCENE2
| Property | Wert | Bedeutung |
|---|---|---|
| <Search_Type>_PATH | z.B. E:/testindex/ccm | Pfad des Index-Verzeichnisses. Als Pfad-Trenner muss “/” benutzt werden, auch bei Windows-Systemen |
Beispiel Extension SEARCH_LAYER_CONFIGURATION
SEARCH_SYSTEM_VENDOR=LUCENE2
SEARCH_TYPES=FULLTEXT,ARCHIVE,CCM,SYSTEMSPLIT_METERINGPOINT,SYSTEMSPLIT_METERINGPOINTTEMP,SYSTEMSPLIT_RESPONSE
ARCHIVE_PATH=E:/index/arc
FULLTEXT_PATH=E:/index/fulltext
CCM_PATH=E:/index/ccm
SYSTEMSPLIT_METERINGPOINT_PATH=E:/index/sysspl1
SYSTEMSPLIT_METERINGPOINTTEMP_PATH=E:/index/sysspl2
SYSTEMSPLIT_RESPONSE_PATH=E:/index/resp
Lucene2Multireader
| Property | Wert | Bedeutung |
|---|---|---|
| <Search_Type>_PATH | z.B. E:/index/arc1; E:/index/arc2 | Falls dieser Implementierung genutzt wird, können in der Pfadangabe mehrere Indexpfade Semikolon-separiert angegeben werden. Der erste Pfad wird als lesender und schreibender Index verwendet, alle anderen Pfade werden als lesende Indexe verwendet. Falls nur ein Pfad angegeben wird, verhält sich dieser Anbieter wie Lucene2. Als Pfad-Trenner muss “/” benutzt werden, auch bei Windows-Systemen |
Die Angabe mehrerer Semikolon-separierter Pfade ist nur in Kombination mit der Extension SEARCH_LAYER_CONFIGURATION sowie mit dem SEARCH_SYSTEM_VENDOR=LUCENE2MULTIREADER möglich. In der alten GlobalProperty B3P_LUCENE_INDEX_FOLDER kann keine Semikolon-separierte Liste angegeben werden.
Beispiel Extension SEARCH_LAYER_CONFIGURATION
SEARCH_SYSTEM_VENDOR=LUCENE2MULTIREADER
SEARCH_TYPES=FULLTEXT,ARCHIVE,CCM,SYSTEMSPLIT_METERINGPOINT,SYSTEMSPLIT_METERINGPOINTTEMP,SYSTEMSPLIT_RESPONSE
FULLTEXT_PATH=E:/index/fulltext
ARCHIVE_PATH=E:/index/arc1;E:/index/arc2;E:/index/arc3
CCM_PATH=E:/index/ccm1
SYSTEMSPLIT_METERINGPOINT_PATH=E:/index/sysspl1
SYSTEMSPLIT_METERINGPOINTTEMP_PATH=E:/index/sysspl2
SYSTEMSPLIT_RESPONSE=E:/index/resp
Lucene2Multireader kann für den CCM-Index nicht generell empfohlen werden! Das Aktualisieren und Löschen von Dokumenten geschieht nur im ersten, schreibenden Index. Im CCM-Index werden aber auch ältere Nachrichten aktualisiert, manchmal auch solche, die vor Wochen erstellt wurden. Wird der schreibende Index als leerer Index angelegt, werden solche Updates nicht klappen.
BDM
Die Installation und Konfiguration des BDM Servers ist hier beschrieben: BDM Administration
| Property | Wert | Bedeutung |
|---|---|---|
| BDM_SEEDS | z.B. 192.168.1.158 | Kommaseparierte IP-Adressen der BDM-Knoten aus topology.xml/node/ip |
| BDM_PORTS | z.B. 2501 | Kommaseparierte Ports der BDM-Knoten aus topology.xml/node/bdm-service-runtime-port |
| BDM_HOST | localhost | B2B Host. Immer localhost |
| BDM_<SEARCH_TYPE> _SERVICE_CLASSNAME |
com.nextlevel.bdm. searchsystem.extension.api. ArchiveSearchSystemService |
Implementierung des Service, der die Verbindung zum BDM-Server realisiert. Siehe unten im Beispiel |
| BDM_FRAME_SIZE | z.B. 300 | Maximale Übertragungsdatengröße in MB bei einer Verbindung mit BDM (z.B Add oder Search) Bei Überschreitung kann der Batch gespaltet werden. |
| BDM_CHECK_FRAME_SIZE | true/false | Soll die Framegröße geprüft werden? |
| BDM_METHOD_CALL_TIMEOUT | z.B. 120000 | B2B wartet bei jeder Anforderung auf die Antwort von BDM. Nach dieser Zeit (Millisekunden) gibt die B2B eine Timeoutfehlermeldung aus, wenn sich BDM nicht meldet. Default=60000 |
| BDM_MAX_RETRY_COUNT | 3 | wenn sich BDM nicht rechtzeitig meldet, wiederholt B2B die Anforderung. Nach maximaler Wiederholung gibt die B2B Timeoutfehlermeldung aus, wenn sich BDM nicht meldet. |
Beispiel Extension SEARCH_LAYER_CONFIGURATION
SEARCH_SYSTEM_VENDOR=BDM
SEARCH_TYPES=ARCHIVE,FULLTEXT,CCM
BDM_SEEDS=192.168.1.158
BDM_PORTS=2501
BDM_HOST=localhost
BDM_ARCHIVE_SERVICE_CLASSNAME=com.nextlevel.bdm.searchsystem.extension.api.ArchiveSearchSystemService
BDM_FULLTEXT_SERVICE_CLASSNAME=com.nextlevel.bdm.searchsystem.extension.api.FulltextSearchSystemService
BDM_CCM_SERVICE_CLASSNAME=com.nextlevel.bdm.searchsystem.extension.api.CCMSearchSystemService
BDM_FRAME_SIZE=300
BDM_CHECK_FRAME_SIZE=true
BDM_METHOD_CALL_TIMEOUT=120000
BDM_MAX_RETRY_COUNT=3
SOLR
Die Installation und Konfiguration von SOLR ist hier beschrieben: SOLR Dokumentation
Solr muss im Cloud-Mode gestartet werden. Für die Konfiguration können daher die URLs aller Solr-Instanzen angegeben werden. Dabei werden die Anfragen gleichmäßig an alle laufenden Knoten verteilt
| Property | Wert | Bedeutung |
|---|---|---|
| SOLR_URLS | z.B. http://host.docker.internal:8981/solr,http://host.docker.internal:8982/solr,http://host.docker.internal:8983/solr | URLs zu allen Solr-Instanzen kommasepariert |
| <Search_Type>_SOLR_COLLECTION | z.b. full | Name der Solr-Collection des Indexes |
| SOLR_PAGE_SIZE | 100000 | Standardmäßig werden Ergebnisse in Seiten je 500.000 Zeilen geladen. Über SOLR_PAGE_SIZE kann eine andere Seitengröße konfiguriert werden. |
| SOLR_TIMEOUT_IN_MILLISECONDS | 1800000 | Timeout für Solr-Anfragen in Millisekunden. Defaultwert ist 10 Minuten |
Beispiel Extension SEARCH_LAYER_CONFIGURATION
SEARCH_SYSTEM_VENDOR=SOLR
SEARCH_TYPES=FULLTEXT,SYSTEMSPLIT_METERINGPOINT,SYSTEMSPLIT_RESPONSE,CCM,ARCHIVE
SOLR_URLS=http://host.docker.internal:8981/solr,http://host.docker.internal:8982/solr,http://host.docker.internal:8983/solr
FULLTEXT_SOLR_COLLECTION=fulltext
SYSTEMSPLIT_METERINGPOINT_SOLR_COLLECTION=systemsplit_meteringpoint
SYSTEMSPLIT_RESPONSE_SOLR_COLLECTION=systemsplit_response
CCM_SOLR_COLLECTION=ccm
ARCHIVE_SOLR_COLLECTION=archive
Momentan ist es noch nicht möglich, den SEARCH_TYPE SYSTEMSPLIT_METERINGPOINTTEMP mit SOLR zu nutzen. Melden Sie sich gerne bei unserem Support, wenn Sie daran Interesse haben.
MULTI
Beim Umstieg von einer Index-Technologie auf eine andere (z.B. von Lucene auf SOLR) ist es hiermit möglich, beide Technologien gleichzeitig zu nutzen. Somit gibt es den neuen Index, welcher primärer Index genannt wird und den alten Index, welcher sekundärer Index genannt wird.
So wird bei einzelnen Operationen verfahren:
- neue Dokumente werden nur im primären Index gespeichert
- beim Lesen werden beide Indexe abgefragt und die Ergebnisse zusammengeführt
- gelöscht wird in beiden Indizes
- Updates werden in dem Index gemacht, in dem sich das upzudatende Dokument befindet
Momentan ist es nur möglich einen sekundären Index anzugeben. Dies kann aber auch erweitert werden. Wenden Sie sich dafür gerne an unseren Support oder die Beratung.
Es ist möglich, dieselbe Technologie für den primären und den sekundären Index anzugeben und so zum Beispiel zwei Lucene-Indexe zusammen zu betreiben.
| Property | Wert | Bedeutung |
|---|---|---|
| MULTI_PRIMARY_SYSTEM | z.B. A, NEU | Name des neuen/primären Index (frei wählbar) |
| MULTI_SECONDARY_SYSTEMS | z.B. B, ALT | Name des alten/sekundären Index (frei wählbar) |
| MULTI_<MULTI_PRIMARY_SYSTEM>_SEARCH_SYSTEM_VENDOR (z.B. MULTI_A_SEARCH_SYSTEM_VENDOR) | z.B. SOLR | Search System Vendor des neuen/primären Index |
| MULTI_<MULTI_SECONDARY_SYSTEM>_SEARCH_SYSTEM_VENDOR (z.B. MULTI_B_SEARCH_SYSTEM_VENDOR) | z.B. LUCENE2 | Search System Vendor des alten/sekundären Index |
| MULTI_<MULTI_PRIMARY_SYSTEM>_<Vendor specific property> (z.B. MULTI_A_ARCHIVE_SOLR_COLLECTION) | z.B. archive | URL- oder Pfadangaben zum Search Type |
| MULTI_<MULTI_SECONDARY_SYSTEM>_<Vendor specific property> (z.B. MULTI_B_ARCHIVE_PATH) | z.B. E:/index/arc | URL- oder Pfadangaben zum Search Type |
Beispiel Extension SEARCH_LAYER_CONFIGURATION
SEARCH_SYSTEM_VENDOR=MULTI
SEARCH_TYPES=FULLTEXT,SYSTEMSPLIT_METERINGPOINT,SYSTEMSPLIT_RESPONSE,CCM,ARCHIVE
MULTI_PRIMARY_SYSTEM=NEU
MULTI_SECONDARY_SYSTEMS=ALT
MULTI_NEU_SEARCH_SYSTEM_VENDOR=SOLR
MULTI_ALT_SEARCH_SYSTEM_VENDOR=LUCENE2
MULTI_NEU_SOLR_URLS=http://host.docker.internal:8981/solr,http://host.docker.internal:8982/solr,http://host.docker.internal:8983/solr
MULTI_NEU_FULLTEXT_SOLR_COLLECTION=fulltext
MULTI_NEU_SYSTEMSPLIT_METERINGPOINT_SOLR_COLLECTION=systemsplit_meteringpoint
MULTI_NEU_SYSTEMSPLIT_RESPONSE_SOLR_COLLECTION=systemsplit_response
MULTI_NEU_CCM_SOLR_COLLECTION=ccm
MULTI_NEU_ARCHIVE_SOLR_COLLECTION=archive
MULTI_ALT_FULLTEXT_PATH=E:/index/fulltext
MULTI_ALT_SYSTEMSPLIT_METERINGPOINT_PATH=E:/index/meteringpoint
MULTI_ALT_SYSTEMSPLIT_RESPONSE_PATH=E:/index/response
MULTI_ALT_CCM_PATH=E:/index/ccm
MULTI_ALT_ARCHIVE_PATH=E:/index/arc
Momentan ist es noch nicht möglich, den SEARCH_TYPE SYSTEMSPLIT_METERINGPOINTTEMP mit SOLR zu nutzen. Melden Sie sich gerne bei unserem Support, wenn Sie daran Interesse haben.
Fehlerbehandlung
Zur Fehleranalyse erhalten alle Einträge in Lucene-Indizes das Feld written. Darin wird das Datum kurz vor dem Schreiben in den Index gespeichert. Dies kann helfen, festzustellen, ob ein Wert zu einem gewissen Zeitpunkt bereits im Index vorhanden war oder nicht. Insbesondere bei Indizes, welche eine INDEX_SYNC-Tabelle (Datenbanktabelle) nutzen, ist dieser Zeitpunkt relevant.