Der Suchdienst nimmt Daten vom Sammlerdienst in Form von XZuFi 2.2 Transferoperationen entgegen und legt diese in ElasticSearch zum Durchsuchen ab. Zusätzlich werden Codelisten abgerufen, um die Suche anzureichern.

Indizierungsprozess:

Das backend speichert alle Daten in ElasticSearch in verschiedenen Indizes.

Achtung: die unten stehenden Namen der Indizes sind symbolisch. Die tatsächlichen Namen entsprechen dem Schema suchdienst_<name><version> und ändern sich daher durch Index-Updates. In ElasticSearch finden sich daher ggf. auch mehrere Versionen eines Index.

Die eigentlichen XZuFi-Daten werden in drei verschiedenen Indizes abgelegt:

• Leistungsbeschreibungen: enthält die LBs. Jede Leistung entspricht einem Dokument in diesem Index. Die LB enthält außerdem die Zuständigkeiten, d.h. eine Liste von IDs von Organisationseinheiten sowie die Menge der ARS, für die die OE diese Leistung verrichtet.
• Organisationseinheiten: enthält die Organisationseinheiten. Wird nicht zum Suchen benutzt, sondern nur zum Laden der OEs anhand ihrer ID.
• Spezialisierungen: enthält die Spezialisierungen. Wird (momentan) auch nur zum Laden anhand von ARS und ID einer LB verwendet.

Die IDs in diesen Indizes entsprechen den IDs, die auch der BeD verwendet.

Der Aufbau der Dokumente entspricht nicht dem XZuFi-Aufbau, sondern ist auf

• gute Such- und Indizierungsperformance, und
• leichte Darstellung in Clients ausgelegt.

Folgende Indizes enthalten weitere Daten, die das Backend benötigt, die aber nicht aus den XZuFi-Daten entnommen werden:

• Ars: enthält die Ortsnamen aller deutschen Gemeinden mit zugehöriger ARS für die Ortssuche. Datenbasis ist momentan GV100 vom statistischen Bundesamt. Es sind auch PLZ enthalten, aber nur die PLZ des jeweiligen Gemeindesitzes.
• Codelistentries: speichert die Codelisten für das Auflösen von Codes. Das Backend versucht, fehlende Codelisten automatisch von xrepository.de zu laden, sie können aber auch über die API hochgeladen werden.
• Settings: speichert Metadaten für die Steuerung des Backends.
• Updatehistory: verwaltet die ausgeführten Indexaktualisierungen (ähnlich wie Liquibase, siehe unter "Index Evolution").

• Es werden nur die Felder durchsuchbar gemacht, die tatsächlich für Suchen benötigt werden. Dadurch werden die Indizes nicht unnötig aufgebläht, sodass die Indizierungs-Performance und das Suchen nicht unnötig verlangsamt werden.
• Es muss beim Index-Design manchmal abgewogen werden, ob eine gute Indizierungsperformance oder eine gute Suchperformance wichtiger ist. Generell sollte die Suchperformance eher im Vordergrund stehen.

Um Hochverfügbarkeit und Skalierung zu ermöglichen, kann das Backend in mehreren Instanzen betrieben werden.

Dazu wird zwischen Master und Satelliten-Instanzen des Backends unterschieden. Pro Cluster muss exakt ein Master betrieben werden. Nur der Master kann Veränderungen am Index vornehmen, also Daten indizieren oder Konfigurationsänderungen durch das Backoffice entgegennehmen.

Zusätzlich können mehrere Satelliten betrieben werden, die nur Suchen ausführen. Suchclients können über LoadBalancer an die Satelliten angebunden werden, um eine höhere Verfügbarkeit zu erreichen.

Beim Starten prüft der Master, ob die Indexstrukturen in ElasticSearch auf dem aktuellen Stand sind und führt ggf. Indexupdates durch. Muss ein Index aktualisiert werden, wird eine neue Version des Index erstellt und die Daten aus der alten Indexstruktur übernommen. Die alten Daten bleiben zunächst erhalten. Auf dieser Basis können die Backend-Instanzen nacheinander aktualisiert werden, sodass durchgehend Suchanfragen beantwortet werden können.

1. Aktualisierung des Masters. Beim Start werden die Indexstrukturen aktualisiert. Die noch laufenden Satelliten beantworten Suchanfragen weiterhin auf Basis der vorherigen Indexstruktur.
2. Der wieder laufende Master fährt mit dem Abrufen von BeD fort, aktualisiert aber nur die neuen Indexstrukturen. Für einen kurzen Zeitraum kann es dazu kommen, dass Suchen auf veralteten Daten ausgeführt werden (insbesondere abhängig von der Dauer der Indexaktualisierung).
3. Sobald der Master wieder online ist, können der Reihe nach alle Satelliten aktualisiert werden. Neue Satelliten-Versionen beantworten Suchanfragen dann wieder auf den aktuellen Indexstrukturen.