Public-Catalog-Suchprojektion kontrolliert neu aufbauen

Diese Betriebsanleitung richtet sich an Systemadministratoren, die den Suchstand eines Tenants nach einem fehlgeschlagenen Update oder auf Anweisung des Supports erneut aufbauen müssen. Im Normalbetrieb übernimmt ProductRelease diesen Schritt automatisch, bevor Workspace den Traffic freigibt.

Nach einem erfolgreichen manuellen Lauf sind PIM-Readiness und Public-Catalog-Suchprojektion für den gewählten Tenant vollständig neu berechnet. Der Befehl veröffentlicht keine Produkte, ändert keine Storefront-Konfiguration und schaltet keinen neuen Such-Reader frei.

Voraussetzungen

  • Die neue Serverversion ist installiert, und der Workspace-Server wurde mit dieser Binary neu gestartet. Nach dem Rebuild ist kein weiterer Neustart erforderlich.
  • Ein lokales nucli-Profil für den System-Tenant ist eingerichtet.
  • Der Systemoperator besitzt taskstream:jobs:execute.
  • Die UUID des Ziel-Tenants ist bekannt.
  • Für die spätere Jobprüfung ist ein Profil des Ziel-Tenants mit taskstream:jobs:read verfügbar.

Prüfen Sie Kontext und Berechtigungen vor dem Auftrag:

bash
nucli --tenant system whoami --scopes
nucli --tenant system skills show pim-public-catalog-search
nucli --tenant system system tenants list --json

Automatischen Update-Lauf beobachten

Nach einem Update baut ProductRelease fehlende Projektionsstände vor der Traffic-Freigabe auf. Bei großen Tenants kann der Status deshalb länger in einer laufenden Phase bleiben:

bash
nucli --tenant system system product-release status --watch --timeout 30m

Der Lauf ist abgeschlossen, wenn ProductRelease ready meldet. Ein Fehler verhindert die Traffic-Freigabe. Workspace verwirft die unvollständige Transaktion; der zuvor vollständig gespeicherte Projektionsstand bleibt erhalten.

Manuellen Neuaufbau starten

Starten Sie den Auftrag nur für die zuvor geprüfte Tenant-UUID:

bash
nucli --tenant system system public-catalog-search rebuild \
  --target-tenant-id <tenant-uuid> \
  --json

Die Antwort enthält jobId, status und alreadyRunning. Bewahren Sie die jobId für die Statusprüfung auf. Wenn alreadyRunning den Wert true hat, verwenden Sie den vorhandenen Auftrag und starten keinen zweiten Lauf.

Jobstatus prüfen

Der Job gehört zum Ziel-Tenant. Prüfen Sie ihn deshalb mit einem berechtigten Profil dieses Tenants:

bash
nucli --tenant <ziel-tenant> api GET /api/v1/jobs/<job-id>

Der Neuaufbau ist erfolgreich, wenn der Job completed meldet. pending, queued oder running sind Zwischenstände. Bei einem großen Katalog kann running länger bestehen bleiben. Währenddessen bleibt für Leser der vorherige vollständige Projektionsstand sichtbar; gleichzeitige Projektionsänderungen desselben Tenants warten auf das Ende der Transaktion.

Fehler einordnen

Ein Job mit failed hat keinen Teilstand veröffentlicht. Prüfen Sie den sanitisierten Jobstatus und die Betriebsdiagnose, beheben Sie die angegebene Ursache und holen Sie vor einem neuen Auftrag erneut eine Freigabe ein. Nutzen Sie weder direkte Datenbankänderungen noch numin, um den Rebuild oder seine Tenant- und Berechtigungsgrenzen zu umgehen.

Wenn ProductRelease betroffen ist, lassen Sie den Server vor der Traffic-Freigabe im Wartungszustand. Weitere allgemeine Diagnosewege finden Sie unter Diagnose und Readiness.

Nächste Schritte

  • Prüfen Sie mit Diagnose und Readiness die allgemeine Betriebsbereitschaft.
  • Nutzen Sie nucli für Profile, Tenant-Guards und sichere JSON-Ausgaben.